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Foreword 



This Technical Specification (TS) was been produced by ETSI Technical Committee Telecommunications and Internet 

converged Services and Protocols for Advanced Networking (TISPAN) and originally published as 

ETSI TS 183 004 [19]. It was transferred to the 3rd Generation Partnership Project (3GPP) in January 2008. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 3, Protocol Description of the Communications Diversion (CDIV) 
supplementary services, based on stage one and two of the ISDN Communication diversion supplementary services. It 
provides the protocol details in the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation 
Protocol (SIP) and the Session Description Protocol (SDP). 

In addition, the "Communication Diversion Notification" (CDIVN) CDIVservice is described in the present document. 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to 
support the CDIV supplementary service. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 22.173: " Multimedia Telephony Service and supplementary services". 

[2] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP". 

[3] IETF RFC 4244: "An Extension to the Session Initiation Protocol (SIP) for Request History 

Information" . 

[4] 3GPP TS 24.623: " Extensible Markup Language (XML) Configuration Access Protocol (XCAP) 

over the Ut interface for Manipulating Supplementary Services". 

[5] IETF RFC 4566: "SDP: Session Description Protocol". 

[6] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[7] IETF RFC 3966: "The tel URI for Telephone Numbers". 

[8] IETF RFC 3325: "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity 

within Trusted Networks". 

[9] 3GPP TS 24.611: "Anonymous Communication Rejection (ACR) and Communication Barring 

(CB); Protocol specification". 

[10] Void. 

[II] 3GPP TS 24.628: "Common Basic Communication procedures; Protocol specification". 
[12] 3GPP TS 23.002: "Network Architecture". 

[13] Void. 

[14] IETF RFC 4458: "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and 

Interactive Voice Response (IVR)". 

[15] IETF RFC 3265: "Session Initiation Protocol (SIP) -Specific Event Notification". 

[16] 3GPP TS 24.629: "Explicit Communication Transfer (ECT); Protocol specification". 
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[17] IETF RFC 3515: "The Session Initiation Protocol (SIP) Refer Method". 

[18] IETF RFC 4745: "Common Policy: A Document Format for Expressing Privacy Preferences". 

[19] ETSI TS 183 004 V2.4.0: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services: Communication Diversion 
(CDIV); Protocol specification". 

[20] IETF RFC 5627 (October 2009): "Obtaining and Using Globally Routable User Agent URIs 

(GRUUs) in the Session Initiation Protocol (SIP)". 

[21] OMA-TS-XDM-Core-Vl_l: "XML Document Management (XDM) Specification", Version 1.1. 

[22] 3GPP TS 24.238: "Session Initiation Protocol (SIP) based user configuration". 

[23] draft-avasarala-dispatch-comm-div-notification-07 (February 2011): "A Session Initiation Protocol 

(SIP) Event Package for Communication Diversion Information in support of the Communication 
Diversion (CDIV) Notification (CDIVN) CDIV service". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 

[24] IETF RFC 3326: "The Reason Header Field for the Session Initiation Protocol (SIP)". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 22.173 [1] and the following 
apply: 

CDIV Session Identifier URI: URI created and inserted by a diverting AS that is routed through the same AS 

NOTE: This is used to solve the service interaction of CDIV and ECT. 
escaped cliaracter: See IETF RFC 3261 [6]. 
transferee: party being transferred to the transfer target 
transferor: party initiating the transfer 
transfer target: party that the existing communication is transferred to 

NOTE: After transfer the transferee and the transfer target are in communication with each other. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACM Address Complete Message 

ACR Anonymous Communication Rejection 

ANM ANswer Message 

AP Authentication Proxy 

AS Application Server 

CB Communication Barring 

CD Communication Deflection 

CDIV Communication Diversion 

CDIVN Communication Diversion Notification 

CFB Communication Forwarding Busy 

CFNL Communication Forwarding on Not Logged-in 

CFNR Communication Forwarding No Reply 

CFNRc Communication Forwarding on subscriber Not Reachable 
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CFU Communication Forwarding Unconditional 

CONF CONFerence 

CPG Call ProGress message 

CSCF Call Session Control Function 

ECT Explicit Communication Transfer 

HOLD communication HOLD 

lAM Initial Address Message 

IFC Initial Filter Criteria 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

ISDN Integrated Service Data Network 

ISUP Integrated Service digital network User Part 

MCID Malicious Communication IDentification 

MGCF Media Gateway Control Function 

OCB Outgoing Communication Barring 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

P-CSCF Proxy-Call Session Control Function 

PSTN Public Switched Telephone Network 

RTP Real-Time Transport Protocol 

S-CSCF Server-Call Session Control Function 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

TIP Terminating Identification Presentation 

TIR Terminating Identification Restriction 

UA User Agent 

UE User Equipment 

URI Universal Resource Identifier 

XCAP XML Configuration Access Protocol 

XML extensible Markup Language 



Communications Diversion (CDIV) 



4.1 



Introduction 



The Communications Diversion (CDIV) service enables diverting user, to divert the communications addressed to 
diverting user to another destination. 



4.2 Description 
4.2.1 General description 



4.2.1.1 



Service description 



The service description of the following CDIVs ervices CFU, CFB, CFNR and CD is based on the PSTN/ISDN 
supplementary services, whereas CFNL is a CDIV service based on requirements for IP based networks and CFNRc is 
based on requirements for mobile networks. 

In addition, CDIVN is a CDIVservice providing the user the capability to receive notifications about all diverted 
communications (CFU, CFB, CFNR, CD, CFNRc and CFNL). 

Generally the following requirements are expected to be fulfilled: 

The service provides for the user or the network to identify an alternative destination for an IP multimedia 
session or individual media of an IP multimedia session. 

The service provides for redirection to be initiated at various stages of an IP Multimedia session. For example: 
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Prior to the set up of an IP Multimedia session. 

During the initial request for an IP Multimedia session (CFU). 

During the establishment of an IP Multimedia session (CD). 

The service provides redirection to be applied for all Multimedia sessions unconditionally or it can be caused by 
any of a set list of events or conditions. Typical causes could be: 

Identity of the originating user. 

Presence of the originating or destination party. 

If the destination party is already in a session (CFB). 

If the destination party is unreachable or unavailable in some other way (CFNL; CFNR, CFNRc). 

If the destination party does not respond (CFNR). 

After a specified alerting interval (CFNR). 

User's preference on routing for specific IP Multimedia session based on the capabilities of multiple UEs 
sharing the same IMS service subscription. 

The sending party, receiving party or the network on their behalf, may initiate redirection to alternative 
destinations. 

The service provides for the user to subscribe to receive notifications of his/her communications diversions as 
dictated by the above requirements. The user will be further able to control: 

If he/she wants to be notified of all or a particular subset of his/her Communication Diversions. 

The amount of information he/she wishes to see as a part of the notifications of his/her CDIV services. 

The time interval or availability instance when he/she wants to be notified of his/her Communication 
Diversions. 

The following services describe applications based on a subset of the above-mentioned requirements to provide user 
different possibilities to divert a communication. 

It should be possible that a user has the option to restrict receiving communications that are forwarded. 

4.2.1.2 Communication Forwarding Unconditional (CFU) 

The CFU service enables a served user to have the network redirect to another user communications which are 
addressed to the served user's address. The CFU service may operate on all communications, or just those associated 
with specified services. The served user's ability to originate communications is unaffected by the CFU supplementary 
service. After the CFU service has been activated, communications are forwarded independent of the status of the 
served user. 

As a service provider option, a subscription option can be provided to enable the served user to receive a reminder 
indication that the CFU service has been activated. This indication is provided when the served user originates a 
communication and if the CFU service has been activated for the served user's address and for the service requested for 
the communication. 

The maximum number of diversions permitted for each communication is a service provider option. The service 
provider defines the upper limit of diversions. When counting the number of diversions, all types of diversion are 
included. 

4.2.1 .3 Communication Forwarding on Busy user (CFB) 

The CFB service enables a served user to have the network redirect to another user communications which are 
addressed to the served user's address and meet busy. The CFB service may operate on all communications, or just 
those associated with specified services. The served user's ability to originate communications is unaffected by the CFB 
supplementary service. 
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As a service provider option, a subscription option can be provided to enable the served user to receive a reminder 
indication that the CFB service has been activated. This indication is provided when the served user originates a 
communication and if the CFB service has been activated for the served user's address and for the service requested for 
the communication. 

The maximum number of diversions permitted for each communication is a service provider option. The service 
provider defines the upper limit of diversions. When counting the number of diversions, all types of diversion are 
included. 

For more information on the procedures for determination of the busy condition see 3GPP TS 24.628 [11]. 

4.2.1 .4 Communication Forwarding on no Reply (CFNR) 

The CFNR service enables a served user to have the network redirect to another user communications which are 
addressed to the served user's address, and for which the connection is not established within a defined period of time. 
The CFNR service may operate on all communications, or just those associated with specified services. The served 
user's ability to originate communications is unaffected by the CFNR supplementary service. 

The CFNR service can only be invoked by the network after the communication has been offered to the served user and 
an indication that the called user is being informed of the communication has been received. 

As a service provider option, a subscription option can be provided to enable the served user to receive a reminder 
indication that the CFNR service has been activated. This indication is provided when the served user originates a 
communication and if the CFNR service has been activated for the served user's address and for the service requested 
for the communication. 

The maximum number of diversions permitted for each communication is a service provider option. The service 
provider defines the upper limit of diversions. When counting the number of diversions, all types of diversion are 
included. 

4.2.1 .5 Communication Forwarding on Subscriber Not Reachable (CFNRc) 

The CFNRc service enables a user to have the network redirect all incoming communications, when the user is not 
reachable (e.g. there is no IP connectivity to the user's terminal), to another user. The CFNRc service may operate on all 
communications, or just those associated with specified services. The user's ability to originate communications is 
unaffected by the CFNRc supplementary service. 

As a service provider option, a subscription option can be provided to enable the user to receive an indication that the 
CFNRc service has been activated. This indication is provided when the user originates a communication if the CFNRc 
service has been activated for the user and for the service requested for the communication. 

The maximum number of diversions permitted for each communication is a service provider option. The service 
provider defines the upper limit of diversions. When counting the number of diversions, all types of diversion are 
included. 

4.2.1.6 Communication Deflection (CD) 

The CD service enables the served user to respond to an incoming communication by requesting redirection of that 
communication to another user. The CD service can only be invoked before the connection is established by the served 
user, i.e. in response to the offered communication (before ringing), i.e. CD Immediate, or during the period that the 
served user is being informed of the communication (during ringing). The served user's ability to originate 
communications is unaffected by the CD supplementary service. 

The maximum number of diversions permitted for each communication is a network provider option. The network 
provider defines the upper limit of diversions. When counting the number of diversions, all types of diversion are 
included. 

4.2.1 .7 Communication Forwarding on Not Logged-in (CFNL) 

The Communication Forwarding on Not Logged-in (CFNL) service enables a served user to redirect incoming 
communications which are addressed to the served user's address, to another user (forwarded-to address) in case the 
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served user is not registered (logged-in). The CFNL service may operate on all communications, or just those associated 
with specified basic services. 

As a service provider option, a subscription option can be provided to enable the served user to receive a reminder 
indication that the CFNL service has been activated. This indication is provided when the served user logs out 
according to procedures described in IETF RFC 3261 [6]. 

The maximum number of diversions permitted for each communication is a service provider option. The service 
provider defines the upper limit of diversions. When counting the number of diversions, all types of diversion are 
included. 

4.2.1.8 Communication Diversion Notification (CDIVN) 

The Communication Diversion Notification (CDIVN) service enables a served user to receive notification about the 
diversion of any of his/her incoming communications, which were addressed to the served user's address. 

As a service provider option, a subscription option can be provided to enable the served user to receive a reminder 
indication that the CDIVN service has been activated. This indication is provided when the served user originates a 
communication and if the CDIVN service has been activated for the served user's address. 

In case the user is not available to receive CDIVN (ex. user is logged out or not reachable) the Notification will be 
provided to the user following the user's registration, in case of CFNL when the user's CDIVN activation is still valid 
and if the time to buffer the Notification (CDIVN Buffer Timer) in the AS has not expired. 

NOTE: In case of CFNL and CRNRc, CDIVN activation continues to be valid after user registration in case the 
user uses the same user's address as before having that status of no connectivity and the time of 
SUBSCRIBE dialog has not expired in the AS. 

4.3 Operational requirements 
4.3.1 Provision/withdrawal 

The CDIV services (Communication forwarding unconditional. Communication forwarding busy. Communication 
forwarding no reply. Communication forwarding not logged-in. Communication deflection and Communication 
Diversion Notification) is provided after prior arrangement with the service provider. 

The CDIV services are withdrawn at the served user's request or for administrative reasons. 

The CDIV supplementary services can be offered separately with subscription options. The notification service CDIVN 
is offered together with at least one CDIV supplementary service. For each subscription option, only one value can be 
selected. These subscription options are part of the call diversion profile for the served user. The subscription options 
are shown in table 4.3.1.1. 
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Table 4.3.1.1 : Subscription options for CDIV services 



Subscription options 


Value 


Applicability 


Served use/receives indication that a 
communication lias been forwarded 
(indication of communication diversion to the 
diverting user). 


No (default) 


CFU 
CFB 
CFNR 
CFNRc 


Yes 


Originating user receives notification that his 
communication has been diverted (forwarded 
or deflected). 


No 


CFU 

CFB 

CFNR 

CFNRc 

CFNL 

CD 


Yes (default) 


Served user allows the presentation of 
diverted to URI to originating user in diversion 
notification. 


No 


CFU 

CFB 

CFNR 

CFNRc 

CFNL 

CD 


Not reveal as GRUU 


Yes (default) 


Served user receives reminder indication on 
outgoing communication that CDIV is 
currently activated. 


No (default) 


CFU 

CFB 

CFNR 

CFNRc 

CFNL 

CDIVN 


Yes 


Served user allows the presentation of his/her 
URI to diverted-to user. 


No 


CFU 

CFB 

CFNR 

CFNRc 

CFNL 

CD 


Not reveal as GRUU 


Yes (default) 


Served user allows the presentation of his/her 
URI to originating user in diversion 
notification. 


No 


CFU 

CFB 

CFNR 

CFNRc 

CFNL 

CD 


Not reveal as GRUU 


Yes (default) 



The following network provider options are available for the CDIV services: 
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Table 4.3.1.2: Network provider options for CDIV services 



Network provider option 


Value 


Applicability 


Served user communication retention on 
invocation of diversion (forwarding or 
deflection). 


Retain communication to the served user until alerting 
begins at the diverted-to user 


CFNR 
CD 


Clear communication to the served user on invocation 
of call diversion 


Served user communication retention 
when diverting is rejected at 
diverted-to user. 


Continue to alert the diverting user (see note 1) 


CFNR 
CD 


No action at the diverting user (see note 2) 


Subscription option is provided for 
"served user receives reminder indication 
on outgoing communication tliat CDIV is 
currently activated". 


No 


CFU 

CFB 

CFNR 

CFNRc 

CFNL 

CDIVN 


Yes 


Total number of all diversions for each 
communication. 


IVIaximum number of diverted connections 
( upper limit is based on operator policy) 


CFU 

CFB 

CFNR 

CFNRc 

CFNL 

CD 


AS behaviour when the maximum number 
of diversions for a communication is 
reached. 


Reject the communication (default) 


CFU 

CFB 

CFNR 

CFNRc 

CFNL 

CD 


Deliver the communication to the latest diverting party 


CDIV Indication Timer. 


Timer duration is a service provider option 


CFU 

CFB 

CFNR 

CFNRc 

CFNL 

CD 


Communication forwarding on no reply 
timer. 


Timer default duration is a service provider option 
(NOTE 3) 


CFNR 


CDIVN Buffer Timer; Timer Value for AS 
to store CDIVN, if it cannot be delivered 
as per CDIVN Configuration. 


Timer duration set by the service provider. Default 
value is 1 day 


CFNL, CFNRc in 
case of CDIVN 


NOTE 1 : This applies to the retention of the communication at invocation of communication diverting. 
NOTE 2: This applies to the clearing communication option on invocation of communication diverting. 
NOTE 3: As a network provider option, it shall be possible to change the timer duration by the served user. 



4.3.2 Requirements on the originating network side 

No specific requirements are needed in the network. 

4.3.3 Requirements in tine network 

No specific requirements are needed in the network. 

Based on the Initial Fiher Criteria (IFC) Rules, indicating that the served user is subscribed to the CDIV supplementary 
services, the communication is be forwarded to an AS. 

NOTE: An example of the use of IFC is shown in annex B. 
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4.4 Coding requirements 

4.4.0 General 

3GPP TS 24.229 [2] defines the messages and parameters for this supplementary service. The following messages and 
parameters are used to support the Communication diversion service due to fulfil the requirements. 

4.4.1 SIP-IVIessages 

4.4.1 .1 SIP messages for redirection 

Table 4.4.1.1 shows the SIP messages that are used due to the coding rules in 3GPP TS 24.229 [2]. 

Table 4.4.1.1 : SIP Header information for redirection 



SIP Message 


Reference 


SIP Header 


INVITE 


[3] 
[8] 
[14] 
[201 


History-Info header 
Privacy header 
cause-param URI parameter 
"gr" URI parameter 


180 (Ringing) 


[3] 
[8] 
[14] 
[20] 


History-Info header 
Privacy header 
cause-param URI parameter 
"gr" URI parameter in the Contact 


181 (Call Is Being Forwarded) 


[3] 
[8] 
[14] 
[20] 


History-Info header 
Privacy header 
cause-param URI parameter 
"gr" URI parameter in the Contact 


200 (OK) response 


[3] 
[8] 
[14] 
[20] 


History-Info header 
Privacy header 
cause-param URI parameter 
"gr" URI parameter in the Contact 


302 (Moved Temporarily) 
(see note) 


[2] 
[14] 


Contact header 
cause-param URI parameter 


NOTE: The 302 (Moved Temporarily) response is in the present document only used for the CD services. 



More information on the cause-param URI parameter is given in annex C. 

An AS that implements the CDIV service shall support the REFER method IETF RFC 3515 [17], to be able to handle 
the interaction with 3GPP TS 24.629 [16]. 

4.4.1.2 SIP messages for CDIVN 

Table 4.4.1.2 shows the SIP messages that are used for the CDIVN according to the coding rules in 

3GPPTS 24.229 [2]. 

Table 4.4.1.2: SIP header information for notification (CDIVN) 



SIP Message 


Reference 


SIP Header 


SUBSCRIBE 


[15] 


Event:comm-div-info 


NOTIFY 


[15] 


Event:comm-div-info 


NOTE: The event package with event name "comm-div-info" based on the SIP Event Notification framework is 
defined in draft-avasarala-dispatch-comm-div-notification [23]. 



For more information on the message body associated with the event package "comm-div-info" refer to subclause 4.10. 
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4.4.2 Parameters 

The Privacy header is described in 3GPP TS 24.229 [2]. The present document refers for the History-Info header to 
IETF RFC 4244 [3], for the Privacy header and P-Asserted-Identity to IETF RFC 3325 [8], for GRUU to 
IETF RFC 5627 [20] and for the cause-param to IETF RFC 4458 [14]. 

4.5 Signalling requirements 

4.5.0 General 

Configuration of supplementary services by the user should: 

take place over the Ut interface using XCAP as enabling protocol as described in 3GPP TS 24.623 [4]; or 

use SIP based user configuration as described in 3GPP TS 24.238 [22]; 

NOTE: Other possibilities for user configuration, such as web-based provisioning or pre-provisioning by the 
operator are outside the scope of the present document, but are not precluded. 

The enhancements to the XML schema for use over the Ut interface is described in subclause 4.9. 

4.5.1 Activation/deactivation 

The services CFU, CFB, CFNR, CFNL, CFNRc and CD are individually activated at provisioning or at the subscriber"s 
request. 

The services CFU, CFB, CFNR, CFNL, CFNRc and CD are individually deactivated at withdrawal or at the 
subscriber" s request. 

For activation of the CDIVN, the message body within the SUBSCRIBE method would be used. Deactivation of 
CDIVN is either explicit by sending SUBSCRIBE message by the served user with "Expires" header set to "zero" or 
upon the expiration of the timer "Expire" in the AS. More details are described in subclause 4.10. 

4.5.1a Registration/erasure 

For registration of diversion information for the services CFU, CFB, CFNR, CFNL, CFNRc and CD, the mechanisms 
specified in subclause 4.5.0 should be used. The diverted-to party address of the services CFU, CFB, CFNR, CFNL, 
CFNRc and CD can individually be registered at the subscriber" s request by using the mechanisms specified in 
subclause 4.5.0. 

For erasure of diversion information for the services CFU, CFB, CFNR, CFNL, CFNRc and CD, the mechanisms 
specified in subclause 4.5.0 should be used. The diverted-to party address of the services CFU, CFB, CFNR, CFNL, 
CFNRc and CD can individually be erased at the subscribers request by using the mechanisms specified in 
subclause 4.5.0. 

Registration/erasure is not applicable for CDIVN. 

4.5.1b Interrogation 

For interrogation of the services CFU, CFB, CFNR, CFNL, CFNRc and CD, the mechanisms specified in 
subclause 4.5.0 should be used. 

For interrogation of the supported conditions and actions that can be used in the network the Ut interface should be 
used. 

Interrogation is not applicable for CDIVN. 
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4.5.2 Invocation and operation 

4.5.2.1 Actions at the originating UA 

A UE supporting CDIV services shall support origination of requests in the IM CN subsystem (as specified in 
3GPP TS 24.229 [2]). 

When communication diversion has occurred on the served user side and the subscription option "Originating user 
receives notification that his communication has been diverted (forwarded or deflected)" is set to true, the originating 
UA may receive a 181 (Call Is Being Forwarded) response according to the procedures described in 

3GPPTS 24.229 [2]. 

The Information given by the History-Info header could be displayed by the UA if it is a UE. 

4.5.2.2 Void 

4.5.2.3 Void 

4.5.2.4 Void 

4.5.2.5 Void 

4.5.2.6 Actions at the AS of the diverting User 

4.5.2.6.0 General 

If the session is subject to diversion the AS of the diverting user: 

if modification of the To header is required as specified in the procedures of this subclause, shall operate as an 
AS providing 3"* party call control, and specifically as a routeing B2BUA, as specified in subclause 5.7.5 of 
3GPPTS 24.229 [2]; 

otherwise, shall operate as either an AS acting as a SIP proxy as specified in subclause 5.7.4 of 

3GPP TS 24.229 [2] or an AS providing 3rd party call control, and specifically as a routeing B2BUA, as 

specified in subclause 5.7.5 of 3GPP TS 24.229 [2] 

NOTE: For the case when the session is not subject to diversion and CDIV, according the requirements in this 
document, is the only service being applied by the AS, then the AS only needs to act as a SIP proxy. If additional 
services are applied, then the AS might need to act as a routeing B2BUA.. 

4.5.2.6.1 Checking of the diversion limits 

When receiving an INVITE request and the AS determines that the AS shall divert a communication the AS shall check 
if diverting the communication exceeds the number of diversions allowed within the network. The AS shall calculate 
the number of diversions by examination of the History-Info header; 

using the entries including a cause-param URI parameter with cause values specified in subclause 4.5.2.6.2.2; or 

examine the entries in the Index entries parameter, 

to see if another diversion is allowed due to network provider allowed limit of diversions 

If the number of diversions exceeds the given limit then: 

If the diverted-to destination is known to be a non-retargeting destination (e.g. Voicemail), then it is based on 
operator policy to allow the communication diversion to be executed. Else; 

If the network option "AS behaviour when the maximum number of diversions for a communication is reached" 
is set to "Reject the communication", then the AS shall send one of the following responses to the originating 
user: 
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a) if communication diversion forwarding busy a 486 (Busy Here); 

b) if communication forwarding no reply, a 480 (Temporarily Unavailable); 

c) if communication forwarding unconditional a 480 (Temporarily Unavailable); 

d) if communication deflection, a 480 (Temporarily Unavailable); 

e) if communication forwarding not logged in, a 480 (Temporarily Unavailable); or 

f) if communication forwarding not reachable, a 480 (Temporarily Unavailable) 

In all cases a Warning header field indicating that the communication is released due to the extension of diversion hops 
(e.g. "Too many diversions appeared") shall be sent. 

If the network option "AS behaviour when the maximum number of diversions for a communication is reached" 
is set to "Deliver the communication to the latest diverting party", then the communication shall be delivered to 
the latest diverting party. 

4.5.2.6.2 Setting of the diversion parameters by the AS 

4.5.2.6.2.1 Overview 

After checking the limit of diversions the following sets the retargeted INVITE request according to the procedures in 

subclause 4.5.2.6.2. 

4.5.2.6.2.2 Diversion where served user is not last in received History-Info header 

If an AS determines that the AS shall divert a communication and if any of the following conditions apply for the 
received INVITE request: 

no History-Info header received; or 

a History-Info header is received in which the last history-info entry contains no hi-targeted-to-uri element for 
the served user. 

The AS shall set the following information in the retargeted INVITE request: 

the diverting parties address; 

the diverted-to party address; 

diversion information. 

The AS shall include or modify the following header fields with the specified values: 

a) The Request URI - set to the SIP URI or tel URI where the communication is to be diverted to (see <target> 
element in subclause 4.9.1.4). 

The AS shall set the cause-param parameter (redirecting reason and redirecting indicator) included in the history- 
info header field according to the diversion conditions. The mapping between the diversion conditions and the 
coding of the cause-param parameter is as follows: 

if communication forwarding busy, the cause value "486" as defined by RFC 4458 [14]; 

if communication forwarding no reply, the cause value "408" as defined by RFC 4458 [14]; 

if communication forwarding unconditional, the cause value "302 as defined by RFC 4458 [14]; 

if communication deflection (Immediate Response), the cause value "480" as defined by RFC 4458 [14]; 

if communication forwarding not logged in , the cause value "404" as defined by RFC 4458 [14]; 

- if communication deflection during alerting, the cause value "487" as defined by RFC 4458 [14];and 
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if communication forwarding on subscriber not reachable, the cause value "503" as defined by 
RFC 4458 [14]; 

b) The History-Info header field - two hist-info entries that shall be generated. 

1) The first entry includes the hi-targeted-to-uri of the served user. 

The AS shall include the privacy header "history" within the hi-targeted-to-uri in the escaped form, if: 

the served user wishes privacy (e.g. the served user is subscribed to the OIR Service); or 

the served user has the subscription option "Served user allows the presentation of his/her URI to 
diverted-to user" set to false. 

Otherwise, if the first entry contains the "gr" parameter and the subscription option "Served user allows the 
presentation of his/her URI to diverted-to user" is set to "not-reveal-as-GRUU", then the AS shall change the 
first entry as follows: 

- replace the first entry with the public user identity of the served user. 

If the diversion is based on a SIP response from the served user, a Reason header in escaped form shall be 
included in accordance with RFC 4244 [3]. 

The Index shall be set or incremented according to the Basic Forwarding rules specified in 
subclause 4.3.3.1.3. "Indexing in the History-Info Header" of IETF RFC 4244 [3]. 

2) The second entry includes the new Request URI as described under bullet a) as hi-targeted-to-uri. 
NOTE: In accordance with RFC 4458 [14], hi-targeted-to-uri will contain a cause-param in non-escaped format. 

c) The To header field: 

If the served user does not want to reveal its identity to the diverted-to party, then the AS shall change the To 
header field to the URI where the communication is diverted to. The served user does not want to reveal its 
identity when one of the following conditions holds true: 

if the served user wishes privacy (e.g. the served user is subscribed to the OIR Service); or 

if the served user has the subscription option "Served user allows the presentation of his/her URI to 
diverted-to user" set to "false". 

Otherwise, if the To header contains the "gr" parameter and the served user has the subscription option "Served 
user allows the presentation of his/her URI to diverted-to user" set to "not-reveal-as-GRUU", then the AS shall 
change the To header field to a public user identity of the served user. 

In all other cases the AS shall not change the To header. 

4.5.2.6.2.3 Diversion with served user last in received History-Info ineader 

If an AS determines that the communication shall be diverted the AS shall apply the procedure in the present subclause 
if the received INVITE request includes a History-Info header, which in the last history-info entry includes a hi- 
targeted-to-uri with an entry for the served user, encoded as in subclause 4.5.2.6.2.2. In this case the AS shall add a new 
history-info entry to the History-Info header field according to the rules defined in IETF RFC 4244 [3]. The following 
information is added to the retargeted request: 

the diverted-to party address; 

diversion information. 

The AS shall add or modify the following header fields with the specified values; 

a) Request URI - set to the SIP URI or tel URI where the communication is to be diverted to (see <target> element 
in subclause 4.9.1.4). 
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The AS shall add the cause-param as defined by RFC 4458[14] to the request URI. The mapping between the 
diversion conditions and the coding of the cause-param parameter shall be as defined under bullet a in 
sublause 4.5.2.6.2.2. 

b) History-Info header field shall be modified in accordance with RFC 4244 [3]. The history entry corresponding 
to previous request URcan be modified. One history entry is added. 

1) The existing history entry corresponding to the previous request URI shall be treated as follows: if the 
Privacy header field does not contain "history", the privacy header "history" in escaped format shall be added or 
modified within the hi-targeted-to-uri, if: 

the served user wishes privacy (e.g. the served user is subscribed to the OIR Service); or 

the served user has the subscription option "Served user allows the presentation of his/her URI to 
diverted-to user" set to false. 

If the history entry representing the served user contains the "gr" parameter and the subscription option 
"Served user allows the presentation of his/her URI to diverted-to user" set to "not-reveal-as-GRUU", the AS 
shall change the history entry to a public user identity of the served user. 

If the diversion is based on a SIP response from the served user, a Reason header in escaped form shall be 
included in accordance with RFC 4244 [3]. user. 

2) A history entry shall be added containing the new Request URI as described under bullet a) as hi- 
targeted-to-uri. 

NOTE: In accordance with RFC 4458 [14], hi-targeted-to-uri will contain a cause-param in non-escaped format. 

c) To header: 

If the served user does not want to reveal its identity to the diverted-to party, then the To header shall be 
changed to the URI where the communication is diverted to. The served user does not want to reveal its 
identity when one of the following conditions holds true: 

- if the served user wishes privacy (e.g. the served user is subscribed to the OIR Service); or 

- if the served user has the subscription option "Served user allows the presentation of his/her URI to 
diverted-to user" set to false. 

Otherwise, if the To header contains the "gr" parameter and the served user has the subscription option 
"Served user allows the presentation of his/her URI to diverted-to user" set to "not-reveal-as-GRUU", then 
the To header shall be changed to a public user identity of the served user. 

In all other cases the To header shall not be changed. 

4.5.2.6.2.4 Overview of the operation 

Figure 4.5.2.6.2.4 shows the example of a communication path for multiple diversions. 
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Figure 4.5.2.6.2.4: Originally A calls B Information transferred in the INVITE request 

Table 4.5.2.6.2.4 shows which parameters and header fields that are added or modified in a diversion AS. 
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Table 4.5.2.6.2.4: Parameter information for multiple redirections 

H0P1 HOP 2 HOPS HOP 4 HOPS 
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U = Value for the cause-param parameter as specified in 4.5.2.6.2.2 and 4.5.2.6.2.3 

V = Value in accordance with the rules in RFC 4244 [3]. 

W = privacy value (history) or (none) or no entry. 

NOTE 1 : The hi-index field shall be set or incremented according to the basic forwarding rules as specified in 

subclause 4.3.3.1 .3 of RFC 4244 [3]. 
NOTE 2: The encoding of the reason header and the contained protocol-cause parameter are specified in 

RFC 3326 [24]. It is embedded in the hi-targeted-to-uri of the history info header in escaped format 

according to the rules in RFC 4244 [3]. 
NOTE 3: The cause-param is specified in RFC 4458 [14]. It is embedded in the hi-targeted-to-uri of the history 

info header in non-escaped format according to the rules in RFC 4458 [14]. 



4.5.2.6.3 Diversion procedures at the diverting AS 

The diverting AS shall continue the communication depending on the service that is causing the diversion: 

1) Communication Forwarding Unconditional or Communication Forwarding Busy network determined user busy 
or Communication forwarding on Not Logged in 

The AS shall continue in the following manner: 

If the notification procedure of the originating user is supported then the originating user shall be notified as 
described in the subclause 4.5.2.6.4. 

An INVITE request containing the diverted-to URI shall sent to the (outgoing) S-CSCF. The INVITE request 
shall includes the parameter information as shown in table 4.5.2.6.2.4 and described in subclause 4.5.2.6.2. 

If the served user has subscribed to the indication of communication diversion to the diverting user and/or 
CDIVN service, then the served user will be indicated to/notified of the communication diversion as 
described in subclause 4.5.2.6.5. 

If the user has activated both CFNL and CDIVN, and CFNL was invoked then the AS will store the 
CDIVN according to the CDIVN Buffer Timer for a default time of 1 day set by the service provider. The 
user has the option of overwriting this timer value in the SUBSCRIBE request to the maximum value of 1 
day. See subclause 4.10.1.1.1.2 for more details. 

2) Communication Forwarding No Reply 

After receiving the first 180 (Ringing) response the no reply timer (definition see subclause 4.8) shall be started. 
If forking is provided by the S-CSCF a further received 180 (Ringing) response does not refresh the timer. 

When receiving any other final response the no reply timer shall be terminated. 

When the no reply timer defined in subclause 4.8 expires: 

The dialog(s) to the diverting user shall be terminated e.g. by sending a CANCEL request or BYE request 
according to the rules and procedures in IETF RFC 3261 [6] , including a Reason header field (see 
RFC 3326 [24]) with the protocol set to "SIP" and the cause set to "408". 



£75/ 



3GPP TS 24.604 version 1 1 .4.0 Release 1 1 22 ETSI TS 1 24 604 V1 1 .4.0 (201 2-1 0) 

If the notification procedure of the originating user is supported then the originating user shall be notified as 
described in the subclause 4.5.2.6.4. 

An INVITE request is sent to the (outgoing) S-CSCF towards the diverted-to user. The INVITE request 
includes the parameter information as shown in table 4.5.2.6.2.4. 

If the served user has subscribed to the indication of communication diversion to the diverting user and/or the 
CDIVN service, then the served user will be notified of the communication diversion as described in 
subclause 4.5.2.6.5. 

3) Communication Forwarding No Reply (ringing continues) 

After receiving the first 180 (Ringing) response the no reply timer (definition see subclause 4.8) shall be started. 
If forking is provided by the S-CSCF a further received 180 (Ringing) response does not refresh the timer. 

When the diverted-to -user has accepted the communication request (with 200 (OK) response) then the 
originating user shall be notified as described in subclause 4.5.2.6.4. 

An INVITE request is sent to the outgoing S-CSCF towards the diverted to user. The INVITE request includes 
the parameter information as shown in table 4.5.2.6.2.4. 

If the served user has subscribed to the indication of communication diversion to the diverting user and/or the 
CDIVN service, then the served user will be notified of the communication diversion as described in 

subclause 4.5.2.6.5. 

If diverting user accepts the communication after sending the INVITE request the communication path towards 
the diverted to user shall be released according to the rules and procedures in RFC 3261 [6]. 

4) Communication Forwarding User Determined Busy 

The Communication Forwarding User Determined Busy is offered to the served user when the AS: 

The received 486 (Busy Here) shall be acknowledged with a ACK request. 

If the notification procedures of the originating user is supported then the originating user shall be notified as 
described in the subclause 4.5.2.6.4. 

An INVITE request containing the diverted-to URI is sent to the outgoing S-CSCF. The INVITE request 
includes the parameter information as shown in table 4.5.2.6.2.4. 

If the served user has subscribed to the indication of communication diversion to the diverting user and/or the 
CDIVN service, then the served user will be notified of the communication diversion as described in 
subclause 4.5.2.6.5. 

5) Communication Deflection immediate response 

The Communication Deflection immediate response is offered to the served user. 

A 302 (Moved Temporarily) response is received. 

If the notification procedures of the originating user is supported then the originating user shall be notified as 
described in subclause 4.5.2.6.4. 

An INVITE request containing the diverted-to URI is sent to the outgoing S-CSCF. The INVITE request 
includes the parameter information as shown in table 4.5.2.6.2.4. 

If the served user has subscribed to the indication of communication diversion to the diverting user and/or the 
CDIVN service, then the served user will be notified of the communication diversion as described in 
subclause 4.5.2.6.5. 

6) Communication Deflection during alerting 

When Communication Deflection during alerting is invoked after the AS receives a 180 (Ringing) "Ringing" 
response, then: 

A 302 (Moved Temporarily) response is received; and 
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if the notification procedures of the originating user is supported then the originating user shall be notified as 
described in subclause 4.5.2.6.4; and 

an INVITE request containing the URI received in the Contact header of the 302 (Moved Temporarily) 
response as the diverted-to URI shall be sent as specified in 3GPP TS 24.229 [2]. The diverted-to URI could 
be restricted by setting the privacy header for the entry of the diverted-to URI to "history"; and 

the INVITE request shall include the parameter information as shown in table 4.5.2.6.2.4 "Parameter 
information for multiple redirection". If the served user has subscribed to the indication of communication 
diversion to the diverting user and/or the CDIVN service, then the served user will be notified of the 
communication diversion as described in subclause 4.5.2.6.5. 

7) Communication Forwarding on Subscriber Not Reachable 

When the AS receives a not reachable indication (see subclause 4.5.2.6.6) on the INVITE request forwarded to 
the served user, then the following criteria shall apply before the Communication Forwarding on Subscriber Not 
Reachable procedure is executed: 

the served user has an active forwarding rule containing not-reachable condition (see subclause 4.9) 

The following steps shall be followed to perform Communication Forwarding on Subscriber Not Reachable: 

1) If the notification procedures of the originating user is supported then the originating user shall be notified as 
described in the subclause 4.5.2.6.4. 

2) An INVITE request with the Request-URI set to the diverted-to URI is sent to the outgoing S-CSCF. The 
INVITE request includes the parameter information as shown in table 4.5.2.6.2.4. 

If the served user has subscribed to the indication of communication diversion to the diverting user and/or CDIVN 
service, then the served user will be indicated to/notified of the communication diversion as described in 
subclause 4.5.2.6.5. 

If the user has activated both CFNRc and CDIVN, and CFNRc was invoked then the AS will store the CDIVN 
according to the CDIVN Buffer Timer for a default time of 1 day set by the service provider. The user has the option of 
overwriting this timer value in the SUBSCRIBE request to the maximum value of 1 day. See subclause 4.10.1.1.1.2 for 
more details. 

4.5.2.6.4 Notification procedures of the originating user (Subscription Option) 

When Communication Diversion occurs and if served user has the subscription option "Originating user receives 
notification that his communication has been diverted (forwarded or deflected)." set to true then a 181 (Call Is Being 
Forwarded) response shall be sent towards the originating user. 

The following header fields shall be included or modified with the specified values: 

a) The P-Asserted-Identity includes the URI of the diverting user. 

b) The Privacy header with the value "id" shall be included, if: 

the served user wishes privacy (e.g. the served user is subscribed to the TIR Service); or 

the served user has the subscription option " Served user allows the presentation of his/her URI to originating 
user in diversion notification." set to false. 

c) The following entries shall be added to the History-Info header field: 

1) If this is the first diversion then the first entry shall be populated with the hi-targeted-to-uri of the served user. 
The Index is set to index = 1 according to the rules specified in IETF RFC 4244 [3]. 

2) On the history entry that represents the served user: 

the privacy header with value "history" shall be escaped within the hi-targeted-to-uri, if: 
the served user wishes privacy (e.g. the served user is subscribed to the TIR Service); or 
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the served user has the subscription option "Served user allows the presentation of his/her URI to 
originating user in diversion notification." set to false. 

If the history is already in the escaped form with the correct privacy value no modification is needed. 

If the history entry representing the served user contains the "gr" parameter and the served user has the 
subscription option "Served user allows the presentation of his/her URI to originating user in diversion 
notification" set to "not-reveal-as-GRUU", it shall be changed to the public user identity of the diverting user. 

In all other cases the history entry representing the served user shall not be changed. 

3) A history entry shall be added according to the rules of subclause 4.5.2.6.2.3 item b.2. In addition, for this 
entry: 

1) if the history entry representing the forwarded to URI contains the "gr" parameter and the served user has 
the subscription option "Served user allows the presentation of forwarded to URI to originating user in 
diversion notification" set to "not-reveal-as-GRUU", it shall be changed to the public user identity of the 
diverted-to user. 

2) the privacy header with value "history" shall be escaped within the hi-targeted-to-uri or the hi-targeted-to- 
uri shall be set to an anonymous value. 

Additionally the AS may initiate an announcement to be included towards the calling user in order to inform about the 
diversion. Announcements may be played according to procedures as are described in 3GPP TS 24.628 [11]. 

4.5.2.6.5 Indication of communication diversion to the diverting user /CDIV Notification, 

(subscription option) 

4.5.2.6.5.0 General 

If the subscription option "Served user receives indication that a communication has been forwarded (indication of 
communication diversion to the diverting user)" has been set to "yes", then one or a combination of the following 
procedures are possible: 

- When the diverting user is registering to the communication system, the AS sends a MESSAGE request 
including the information where his calls are diverted to if any. As an option; the MESSAGE request may be 
sent to the user after a period of time according to the timer value CDIV Indication Timer as defined in subclause 
4.8.3 that can be provided by the user. 

- A diverting user will be informed periodically with a MESSAGE request the information where the call is 
diverted to. 

NOTE 1 : A diverting user could be informed via a Voicemail or Message mail system in the communication states 
described above. 

If the subscription option "Served user receives reminder indication on outgoing communication that CDIV is 

currently activated" has been set to "yes", then a diverting user will be informed with a MESSAGE request after 
the diverting user has initiated a new outgoing communication. The MESSAGE request includes the information 
where the call is diverted to. 

NOTE 2: A diverting user could be informed via a Voicemail or Message mail system in the communication states 
described above. 

The description of information text contained in the MESSAGE request is out of scope of the present document. 

If CDIVN has been activated according to subclause 4.5.1, then: 

The diverting AS will invoke the CDIV Notification to notify the diverting user when CDIV is performed. This 
notification is applicable for all the communication diversions which were selected by the user whilst 
subscribing to the CDIVN service. 
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4.5.2.6.5.1 Communication Diversion Notification procedure of tine served user 

When Communication Diversion occurs and if the CDIVN service of the served user is supported in the network and 
the user has activated the CDIVN service according to subclause 4.5.1, the user will receive a NOTIFY request 
according to preferences passed in the SUBSCRIBE request. 

In case of CFNL and CFNRc, the AS will store the CDIVN for a period of time, see subclause 4.5.2.6.3. Upon user's 
registration, if previous subscription is not valid at that point of time (see subclause 4.2.1), the user may activate 
CDIVN by sending SUBSCRIBE request. As a consequence, the user will receive a NOTIFY request accordingly 
including his stored notifications. 

If the served user has subscribed to the Communication Diversion Notification service, then the diverting AS continues 
in the following manner: 

Identify and match the communication diversion selection criteria as mentioned by the user to select the 
communication diversions which have to be notified to the user. Such selection may be based on: 

Identity of the Originating user. 

Identity of the served user. 

Identity of the diverted-to user. 

Time-range of the Communication Diversion. 

Reason for the Communication Diversion. 

Identify the amount of information which the served user has selected for including in the notification. By 
default, all the following information should be sent to the user. The served user has the option of disabling any 
of the following information, if he/she is not interested in: 

information about the originating user; 

information about the served user; 

information about the diverted-to user; 

time of the Communication Diversion; 

reason for the Communication Diversion; 

information about the rule which triggered the communication diversion. 

Identify the trigger criteria of sending the notification to the served user. By default, the notification should be 
sent immediately to the served user otherwise it may be based on the following: 

Suitable Time-range for delivering the notification. 

A particular availability status of the served user. 

4.5.2.6.5.2 Interaction of CDIVN and Indication of communication diversion to the diverting user 
procedures 

If the CDIVN service of the served user is not supported in the network, then the indication of communication diversion 
to the diverting user for the communication diversion services shall apply. 

If the CDIVN service of the served user is supported in the network but has not activated the CDIVN service according 
to subclause 4.5.1, then the indication of communication diversion to the diverting user for the communication 
diversion services shall apply. 

4.5.2.6.6 Not reachable indication 

It is recommended that the AS interprets the reception of one of the following response events as not reachable 
indication: 

408 (Request timeout) response; 
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503 (Service unavailable) response; 

500 (Server Internal Error) response; 

and no provisional response, different than a 100 (Trying) response, has been received on the same dialog. 

NOTE: There may be other means to discover this condition. These other means are out of the scope of the 
present document. 



4.5.2.7 



Actions at the AS of the diverted-to user 



If the session is diverted, the AS of the diverted-to user shall operate either as an AS acting as a SIP proxy as specified 
in subclause 5.7.4 of 3GPP TS 24.229 [2] or an AS providing 3rd party call control, and specifically as a routeing 
B2BUA, as specified in subclause 5.7.5 of 3GPP TS 24.229 [2]. 

NOTE: For the case when the session is not subject to diversion and CDIV, according the requirements in this 
document, is the only service being applied by the AS, then the AS only needs to act as a SIP proxy. If additional 
services are applied, then the AS might need to act as a routeing B2BUA.. 

The AS shall store the History-Info header of an incoming Request. 

If a 180 (Ringing), 181 (Call Is Being Forwarded) or 200 (OK) response does not contain a History-Info header field, 
the AS shall include the stored History -Info header field. If diverted-to user is subscribed to the TIR service, in the 
Privacy header field of all responses the priv-value of the last entry in the History- Info header field shall be set to 
"history". 

NOTE: A response including no History-Info header Field is coming from an untrusted entity or the History-Info 
header field is not included due to the privacy status within the SIP request. 



4.5.2.8 



Void 



4.5.2.9 



Void 



4.5.2.10 



Void 



4.5.2.11 



Void 



4.5.2.12 



Void 



4.5.2.13 



Void 



4.5.2.14 



Void 



4.5.2.15 



Actions at the diverted to UA 



A UE supporting CDIV services shall support termination of requests in the IM CN subsystem (as specified in 3GPP TS 

24.229 [2]). 

4.5.2.16 Actions at the diverting UA 

A UE supporting CDIV services (e.g. CFU, CFB, CFNR, CD, CFNRc and CFNL) shall support termination of requests 
in the IM CN subsystem (as specified in 3GPP TS 24.229 [2]). If the UE is intended to support the user subscription 
option of "indication of communication diversion to the diverting user", this support shall include the receipt of 
MESSAGE requests (as specified in 3GPP TS 24.229 [2]). 

Additionally, a UE supporting CDIVN shall support initiation of dialogs using a SUBSCRIBE request (as specified in 
3GPP TS 24.229 [2]). 
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To invoke Communication Deflection the UA shall send a 302 (Moved Temporarily) response to the INVITE request 
including a Contact header field with the address where the communication is diverted to. 

4.6 Interaction with other services 

4.6.1 Communication Hold (HOLD) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.2 Terminating Identification Presentation (TIP) 

When a communication has been diverted, in order to provide the originating user with information about the diverted- 
to identity, the diverting AS shall include a SIP or TEL URI of the diverted-to user into a History-Info header field in a 
181 (Call Is Being Forwarded) response message and send it to the originating AS, unless the diverting user has 
selected the option to suppress the notification of diversion. As it is not known what the diverted-to user's TIR settings 
are, a privacy header field with a priv-value set to "history" needs to be included in escaped form in the hi -entry 
representing the diverted-to user; or the URI representing the diverted-to user may be set to an anonymous value. 

A P-Asserted-Identity and History-Info header field received in the diverting AS is passed unmodified to the originating 
entity. 

NOTE: The originating P-CSCF is responsible for the interpretation of the privacy header field as described in 

3GPPTS 24.229 [2]. 

4.6.3 Terminating Identification Restriction (TIR) 

A P-Asserted-Identity and History-Info header field received in the diverting AS is passed unmodified to the originating 
entity. If TIR applies for the served user, the diverting AS shall add a Privacy header field set to "id" and if a Privacy 
header field set to "none" is received the diverting AS shall remove it. If a Privacy header field set to "id" is received 
from the diverted-to user the diverting AS shall pass it unchanged to the originating user. 

NOTE: The originating P-CSCF is responsible of the interpretation of the privacy header field as described in 

3GPPTS 24.229 [2]. 

If the served (diverting) user selects the option that the originating user is notified, but without the diverted-to SIP or 
TEL URI, then the AS shall send a 181 (Call is Being Forwarded) response and either 

escape a Privacy header field with a priv-value set to "history" in the hi-entry representing the diverted-to user; 
or 

anonymize the hi-entry representing the diverted-to user. 

When the TIR service has been invoked by the diverted-to user, the diverted-to user's address and name shall not be 
presented in the CDIVN notification body in the NOTIFY request. 

4.6.4 Originating Identification Presentation (OIP) 

When a communication has been diverted and the diverted-to user has been provided with the OIP service, normal 
procedures apply in the IMS network serving the diverted-to user. The diverting AS shall pass all received privacy 
headers unmodified. The diverting AS shall add the identity of the diverting user in the History-Info header field with 
an embedded Privacy header reflecting the served users privacy settings. 

4.6.5 Originating Identification Restriction (OIR) 

When the OIR service has been invoked, normal procedures apply in the IMS network serving the diverted-to user. The 
diverting AS shall pass all received privacy headers unmodified. The diverting AS shall add the identity of the diverting 
user in the History-Info header field with an embedded Privacy header reflecting the served users privacy settings. 

When the OIR service has been invoked by the originating user, the diverting AS shall remove the originating user's 
address and name in the CDIVN notification body in the NOTIFY request. 
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NOTE: The P-CSCF executes the related privacy procedures as described in 3GPP TS 24.229 [2]. 

4.6.6 Conference calling (CONF) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.7 Communication Diversion Services (CDIV) 

CPU, CFNL, and CFB when NDUB is used are all determined immediately when an INVITE request is received, and 
take precedence over CDIV services that are based on a response (CD, CFNRc, CFNR, and CFB when UDUB is used). 
CFU take precedence over all other CDIV services and the CDIV AS must evaluate the rule associated with CFU before 
CFNL and CFB when NDUB is used. As CFNL and CFB cannot occur simultaneously there is no interaction. For CDIV 
services that are based on a response, the response received first will invoke the associated CDIV service. 

For the CDIVN service and the indication of communication diversion to the diverting user service, the provision and 
activation of at least one redirection service is a pre-requirement to provision and activate the CDIVN service and the 
indication of communication diversion to the diverting user service 

4.6.8 Malicious Communication Identification (MCID) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.9 Anonymous Communication Rejection and Communication Barring 
(ACR/CB) 

If the user where the communication is forwarded to has subscribed to a call barring service "inhibition of incoming 
forwarded communication" the procedures described in 3GPP TS 24.61 1 [9] shall take precedence. 

If the OCB service has already been activated, the CDIV AS shall reject a request to activate any CDIV service if the 
forwarding party"s communication to the diverted-to party would be barred by the OCB service. 

If the CDIV service was activated before the activation of the OCB service, the OCB service can still be activated. 
When the two services have already been activated, the CDIV AS shall not invoke the CDIV service if the forwarding 
party's communication to the diverted-to party would be barred by the OCB service at the time of the invocation attempt 
of the CDIV service. 

4.6.1 Explicit Communication Transfer (ECT) 
4.6.1 0.1 Actions at the diverting AS 

4.6.1 0.1 .1 Determine whether ECT is applied to the diverted communication 

See 3GPP TS 24.629 [16] on the criteria that determine that a REFER request is to be treated as a request for transfer of 
an existing communication. 

4.6.10.1.2 Handling of transfer requests 

When a REFER request is received towards the originating user in the context of a call transfer scenario (see subclause 
4.6.10.1.1), the diverting AS shall perform the following steps: 

1) Create a new CDIV Session Identifier URI addressed to this AS. The URI shall be created in such a way that a 
new dialog set up towards this URI can be easily correlated with the current REFER dialog. 

2) The AS stores the value of the Refer-To header field (transfer target) from the REFER request and links it to the 
CDIV Session Identifier URI. 

3) The AS Replaces the Refer-To header field with the CDIV Session Identifier URI. (This ensures that the 
diverting AS remains in the loop when the transferee sets up the communication with the transfer target.). 
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4) The AS forwards the REFER request to the transferee using basic communication procedures 

3GPPTS 24.229 [2]. 

A REFER request received towards the diverted-to user is forwarded using normal procedures. 

4.6.1 0.1 .3 Actions when CDIV is invoked again by the transferred communication 

When an INVITE request is received targeted at the CDIV Session Identifier URI created earlier when transfer of the 
diverted ongoing communication was requested, the AS shall perform the following actions: 

1) The AS replaces the request URI with the stored Refer-To header field value linked to the specific CDIV Session 
Identifier URI. 

NOTE: If needed the AS may generate charging events to charge for the extra leg. 

2) Void. 

3) The AS forwards the INVITE request towards the transfer target using basic communication procedures 
3GPPTS 24.229 [2]. 

4.6.1 1 Communication Waiting (CW) 

Communication Forwarding Unconditional (CFU): CW has no impact on CFU. The communication will be 
forwarded without regard to the terminating party's state. The CFU service can be activated while a call is waiting 
without changing the state of the waiting call. A forwarded communication can result in the communication waiting 

service. 

Communication Forwarding Busy (CFB): No impact, i.e. neither service affects the operation of the other service. A 
forwarded communication can result in the communication waiting service. 

NOTE: If the terminating party is NDUB, the CW service will not be invoked, and the CFB service is invoked if it 
was activated. 

Communication Forwarding No Reply (CFNR): If the terminating party has activated the CFNR service, then the 
CW AS still shall offer a waiting communication. If the CFNR timer expires before an answer is received then the 
CFNR service shall be invoked and the CDIV AS shall forward the communication. The CDIV AS cancels the 
communitication to the served user. A forwarded communication can result in the communication waiting service. 

Communication Forwarding on Not Logged-in (CFNL): No impact, i.e. neither service affects the operation of the 
other service. 

NOTE: If a party with an active communication waiting logs out, all active and offered communications would be 
released. 

Communication Deflection (CD): When receiving the communication waiting indication, terminating party can 
invoke the CD service. A deflected communication can result in the communication waiting service. 

Communication Forwarding on Subscriber Not Reachable (CFNRc): No impact, i.e. neither service affects the 
operation of the other service. 

4.6.12 Completion of Communications to Busy Subscriber (CCBS) 

The CC AS shall not divert a CC recall. It shall provide the CC recall to the original originating party. 

4.6.13 Advice Of CInarge (AOC) 

No impact, i.e. neither service affects the operation of the other service. 
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4.7 Interworking with other networks 

4.7.1 Void 

4.7.2 Void 

4.7.3 Void 

4.8 Parameter values (timers) 

4.8.1 No reply timer 

No reply timer: Timer duration shall be a service provider option. 

4.8.2 CDIVN Buffer Timer 

CDIVN Buffer Timer: operator's option (default = 86 400 sec), may be overwritten by the user in the SUBSCRIBE 
message-Notification Buffer Interval. 

Notification Buffer Interval: sec - 86 400 sec. 

4.8.3 CDIV Indication Timer 

CDIV Indication Timer: 60 sec to 00 sec. 

The timer is started when the diverting user is registering to the communication system. Based on operator policy the 
user has the possibility to choose a certain timer value within the defined range. 

4.9 Service Configuration for redirection services 

4.9.1 Structure of the XML Document 
4.9.1.0 General 

Communication Diversion documents are subtrees of the simservs document specified in 3GPP TS 24.623 [4]. As such, 
Communication Diversion documents use the XCAP application usage in 3GPP TS 24.623 [4]. 

In addition to the considerations and constraints defined by the simservs document 3GPP TS 24.623 [4], we define the 
additional constraints and considerations for the Communication Diversion subtree: 

XML schema: Implementations in compliance with the present document shall implement the XML schema that 
minimally includes the XML Schema defined in subclause 4.9.2 and the simservs XML schema specified in 
3GPPTS 24.623 [4]. 

Data semantics: The semantics of the communication diversion XML configuration document is specified in 
subclause 4.9.1. 

An instance of the supplementary services configuration containing a communication diversion configuration 
document. 

<?xml version="l . 0" encoding="UTF-8" ?> 
<simservs 

xmlns="http : //uri . etsi . org/ngn/params/xml/simservs/xcap" 
xmlns : cp="urn: ietf :params :xml :ns : common-policy" 
xmlns :ocp="urn:oma :xml :xdm: common-policy" > 
<communication-diversion active="true" > 
rule set 
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< /communication- divers ion> 
</simservs> 

The communication diversion service contains a rule set that specifies how the communication diversion service shall 
react to external stimuli. 

4.9.1.1 Communication Diversion Element 

The communication diversion configuration contains a noReplyTimer element, a rule set, or a noReplyTimer element 
followed by a rule set. 

The rule set reuses the syntax as specified by the common policy draft (see RFC 4745 [18]). 

<communication-diversion active="true" > 

<NoReplyTimer>i\roJ?eplyTinierValue< /NoReplyTimer > 
<cp : ruleset> 

rulel 
rule2 
</cp : ruleset> 
< /communication- divers ion> 

In general the following procedure applies: 

When the service processes a set of rules it shall start executing the first rule. If: 

the rule has no <conditions> element; 

the rule has an empty <conditions> element; or 

conditions are present and they all evaluate to true; 

then the rule matches and the specified action shall be executed. 

When the rule does not match the following rule shall be selected and the same procedure repeated, until a matching 
rule is found or the set of remaining rules is empty. 

However not all rules can be matched at the same moment in the call. Some conditions imply that rules that carry them 
are checked at specific events in the call, for example the no-answer condition only holds when the called party does not 
answer after a while. In this case the same procedure shall apply as above with the modification that the set of rules to 
process contains only the rules applicable for that specific network event. 

In subclause 4.9.1.3 all allowed conditions are specified, normally rules are evaluated at communication setup time, for 
conditions where this is not the case this is explicitly indicated. 

The shown "active" attribute is inherited from the simservType from 3GPP TS 24.623 [4], its meaning is also specified 
in 3GPP TS 24.623 [4]. 

4. 9. 1.1 A NoReplyTimer 

NoReplyTimer: An optional element that covers the time to elapse until the communication diversion shall perform, if 
the served user does not answer when alerted. 

4.9.1.2 Communication Diversion Rules 

The Communication Diversion service is configured with an ordered set of forwarding rules. The XML Schema reuses 
the rule syntax as specified by the common policy draft (see IETF RFC 4745 [18]). The rules take the following form: 

<cp:rule id= "rule55"> 
<cp : conditions> 
conditionl 
condition2 
</cp : conditions> 
<cp : actions> 

<f orward-to> 
<target> 

target Addressl 
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</target> 

<notify-caller>true</notify-caller> 
< /forward- to> 
</cp : actions> 
</cp : rule> 



To give more guidance, an example of such a rule is shown below: 

<cp:rule i.d=" rule66"> 

<cp : conditions> 

<ss :busy/> 

<ss :media>PCMA</ss :media> 
<cp : identity> 

<cp : one>id=serveduser®domain</cp : one> 
</cp : identity> 
</cp : conditions> 
<cp : actions> 

<forward-to> 
<target> 

targe tAddressl 
</target> 

<notify-caller>true</notify-caller> 
< /forward- to> 
</cp : actions> 
</cp : rule> 



When the service processes a set of rules it shall start executing the first rule. If: 

the rule has no <conditions> element; 

the rule has an empty <conditions> element; or 

conditions are present and they all evaluate to true; 

then the rule matches and the specified action is executed. When a rule matches remaining rules in the rule set shall be 
discarded. Applied to the fragment above this means that only if the expression (condition! AND conditioni) evaluates 
to true that then the rule66 matches and the forward-to action is executed. 

When the rule does not match the following rule shall be selected and the same procedure repeated, until a matching 
rule is found or the set of remaining rules is empty. 

The "id" attribute value of a rule shall uniquely identify the rule within a rule set. This can be used in XCAP usage to 
address one specific rule. 



4.9.1.3 



Communication Diversion Rule Conditions 



The following conditions are allowed by the XML Schema for the communication diversion service: 

busy: This condition evaluates to true when the called user is busy. In all other cases the condition evaluates to false. 
Rules with this condition are evaluated when a busy indication is received. Receipt of a SIP 486 (Busy Here) response 
is a busy indication. 

not-registered: This condition evaluates to true when the called user is not registered. In all other cases the condition 
evaluates to false. 

presence-status: This condition evaluates to true when the called user's current presence activity status is equal to the 
value set for this condition. In all other cases the condition evaluates to false. 

cp:identity: This condition evaluates to true when the calling user's identity matches with the value of the identity 
element. The interpretation of all the elements of this condition is described in OMA-TS-XDM-Core-Vl_l [21]. In all 
other cases the condition evaluates to false. The Identity shall be matched against the value taken from the P-Asserted- 
Identity header field, and in addition as an option matched against the From header field and/or the Referred-By header 
field, unless both the <identity> element value and the Contact header field value contain a "gr" parameter, then the 
<identity> element value shall be matched against the value taken from the Contact header field. 

anonymous: This condition evaluates to true when the P-Asserted-Identity of the calling user is not provided or privacy 
restricted. 
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cp:sphere: Not applicable in the context of the Communication Diversion service. 

cp:validity: Specifies a period. The condition evaluates to true when the current time is within the validity period 
expressed by the value of this condition. In all other cases the condition evaluates to false. 

media: When the incoming call request for certain media, the forwarding rule can decide to forward the call for this 
specific media. This condition evaluates to true when the value of this condition matches the media field in one of the 
"m=" Unes in the SDP (IETF RFC 4566 [5]) offered in an INVITE request (IETF RFC 3261 [6]). 



no-answer: This condition evaluates to true when the called user does not answer. In all other cases the condition 
evaluates to false. Rules with this condition are evaluated when a no-answer timeout is detected or when a no answer 
indication is received.. 

rule-deactivated: This condition always evaluates to false. This can be used to deactivate a rule, without loosing 
information. By removing this condition the rule can be activated again. 

ocp:external-list: This condition evaluates to true when the calling users identity is contained in an external resource list 
to which the value of external-list refers. The exact interpretation of this element is specified in OMA-TS-XDM-Core- 

Vl_l [21]. 

ocp:other-identity: Not applicable in the context of communication diversion service. 

not-reachable: This condition evaluates to true when there is a signalling channel outage during session setup to the 
served user's UE. Receipt of a 500 (Server Internal Error) response is an indication that the served user's UE is 
unreachable. In all other cases this condition evaluates to false. 

NOTE 1: As described in IETF RFC 4745 [18] the case of unconditional evaluates to be true in all cases where all 
other reasons are not applicable. A communication diversion is performed as soon as the served user is 
the called user. The indication of unconditional is the absence of any reason element in the ss:condition 
element. 

NOTE 2: The UE being not reachable does not include being not registered. 

The condition elements that are not taken from the common policy schema (see IETF RFC 4745 [18]) or oma common 
policy schema (see OMA-TS-XDM-Core-Vl_l [21]) are defined in the simservs document schema specified in 
3GPPTS 24.623 [4]. 

Information of which of the above mentioned conditions the user is allowed to use can be obtained from the network by 
using the schema defined in subclause 4.9.3. 

The "serv-cap-media" element lists the elements that can be used in the "media" rule condition. 

4.9.1.4 Communication Diversion Rule Actions 

The action supported by the CDIV service is forwarding of calls. For this the forward-to action has been defined. The 
forward-to action takes the following elements: 

target: Specifies the address of the forwarding rule. It should be a SIP URI (IETF RFC 3261 [6]) or TEL URL 
(IETF RFC 3966 [7]). 

notify-caller: An optional element that can be used to disable the default behaviour that the caller is notified that the call 
is being forwarded, (see subscription option "Originating user receives notification that his communication has been 
diverted (forwarded or deflected)" in table 4.3.1.1) 

reveal-served-user-identity-to-caller: An optional element that can be used to disable the default behaviour that the 
caller, when notified that the call is being forwarded, receives the diverting party's identity information, (see 
subscription option "Served user allows the presentation of his/her URI to originating user in diversion notification" in 
table 4.3.1.1) 

reveal-identity-to-caller: An optional element that can be used to disable the default behaviour that the caller, when 
notified that the call is being forwarded, receives some diverted-to party's identity information, (see subscription option 
"Served user allows the presentation of diverted to URI to originating user in diversion notification" in table 4.3.1.1) 
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notify-served-user: An optional element that can be used to enable that the served user is indicated that calls are being 
forwarded. Default this is switched off (see subscription option "Served user receives indication that a communication 
has been forwarded (indication of communication diversion to the diverting user)" in table 4.3.1.1) 

notify-served-user-on-outbound-call: An optional element that can be used to enable that the served user is notified that 
calls are being forwarded when he makes a call attempt. Default this is switched off. (see subscription option "Served 
user receives reminder indication on outgoing communication that CDIV is currently activated" in table 4.3.1.1) 

reveal-identity-to-target: An optional element that can be used to disable the default behaviour that the diverted-to party 
receives some identity information of the diverting party, (see subscription option "Served user allows the presentation 
of his/her URI to diverted-to user" in table 4.3.1.1) 

Information of which of the above mentioned actions the user is allowed to use can be obtained from the network by 
using the schema defined in subclause 4.9.3. The 'serv-cap-target' element indicates whether the user is allowed to use 
any URI as target or whether the target needs to correspond to a telephone number, i.e. a SIP URI with a "user" URI 
parameter set to "phone" or a tel URI. 

4.9.1 .5 Supported Actions and Conditions for Communication Diversion 

The supported actions and conditions for communication diversion are configured with a list of action capability and 
condition capability elements. These capability elements are read only and indicate which capabilities related to 
communication diversion the network has provisioned for a user. 

EXAMPLE: An instance of the simulation services configuration containing a service capabilities document for 
communication diversion is shown in the following example. It is based on operator policy if the 
restriction of <serv-cap-target> element to <telephony-type> is needed. In this example, the same 
capabilities as in call diversion in a CS network are supported. 

<?xml version="l . 0" encoding="UTF-8" ?> 
<simservs 

xmlns="http : //uri . etsi .org/ngn/params/xml/simservs/xcap" > 
<communication-diversion-serv-cap active="true" > 
<serv- cap -condit ions > 

<serv- cap- external -list provisioned=" false" ></serv- cap- external- list > 
<serv- cap -identity provisioned="f alse"></serv-cap-identity> 
<serv- cap -media > 

<media>audio< /media > 
<media>video< /media > 
</serv- cap -media > 
<serv- cap-presence- status provisioned=" false" ></serv- cap-presence- status > 
<serv- cap -validity provisioned=" false" ></serv-cap-validity> 
< /serv- cap -condit ions > 
< serv- cap -act ions > 

< serv- cap -target> 

< telephony- type/ > 
< /serv- cap -target> 

< serv- cap -notify- served- user- on- outbound- call provisioned=" false" > 
</ serv- cap -notify- served- user- on- outbound- call> 
< serv- cap -reveal -identity- to -caller provisioned=" false" > 

< /serv- cap -cap -reveal -identity- to -caller> 
< serv- cap- reveal -served-user- identity- to -caller provisioned=" false" > 

</ serv- cap- reveal -served-user- identity- to -caller> 
< serv- cap -reveal -identity- to -target provisioned=" false" > 
< /serv- cap -reveal -identity- to -target> 
< /serv- cap -act ions > 
< /communication- divers ion- serv- cap > 
</simservs> 



4.9.2 XML Schema 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www.w3 . org/2 01/XMLSchema" 

xmlns : ss="http : //uri .etsi .org/ngn/params/xml/simservs/xcap" 

xmlns : cp="urn: ietf :params :xml :ns : common-policy" 

xmlns :ocp="urn:oma :xml :xdm: common -policy" 

targetNamespace="http : //uri .etsi .org/ngn/params/xml/simservs/xcap" 

elementFormDefault=" qualified" 

attributeFormDefault= "unqualified" > 
<!-- import common policy definitions --> 
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<xs : import namespace="urn: ietf iparams :xml :ns : common-policy" schemaLocat ion=" common-policy .xsd"/> 
<!-- import OMA common policy extensions --> 

<xs : import namespace="urn:oma :xml :xdm: common-policy" schemaLocat ion="xdm_commonPol icy- V1_0 .xsd"/> 
<!-- communication diversion specific extensions to IETF common policy conditions. The 
cp : conditionsType is expanded with the elements: ss mot-registered, ssibusy, ss :no-answer, ssmot- 
reachable, ss: media as optional elements --> 

<!-- communication diversion rule set based on the common policy rule set.--> 
<xs : element name=" communication- divers ion" substitutionGroup="ss : absService" > 
<xs : annotation> 

<xs :documentation>This is the communication diversion configuration 
document . </xs : documentation> 
</xs : annotation> 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="ss : simservType" > 
<xs : sequence> 

<!-- add service specific elements here--> 
<xs: element ref ="ss iNoReplyTimer" minOccurs=" 0"/> 
<xs: element ref ="cp : ruleset" minOccurs=" 0"/> 
</xs : sequence> 
</xs : extension> 

<!-- service specific attributes can be defined here --> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

<!-- communication diversion specific extensions to IETF common policy actions--> 
<xs:element name=" forward- to" type="ss : forward-to-type"/> 
<xs : simpleType name="reveal-URI-options-type" > 
<xs : restriction base="xs : string" > 
<xs : enumeration value= " false" /> 
<xs : enumeration value=" not- reveal -GRUU"/> 
<xs : enumeration value="true"/> 
</xs : restriction> 
</xs : simpleType> 

<!-- communication diversion specific type declarations --> 
<xs : complexType name=" forward- to- type" > 
<xs : sequence> 

<xs:element name="target" type="xs : anyURI" minOccurs="l" maxOccurs="l"/> 
<xs:element name="notify-caller" type="xs : boolean" def ault="true" minOccurs="0"/> 
<xs : element name=" reveal -identity- to -caller" type="ss : reveal -URI- opt ions -type" 
def ault = " true " minOccurs= " " / > 

<xs : element name=" reveal -served-user- identity- to- caller" type="ss : reveal -URI -opt ions - 
type" def ault="true" minOccurs="0"/> 

<xs:element name="notify-served-user" type="xs : boolean" def ault="f alse" minOccurs="0"/> 
<xs: element name="notify-served-user-on-outbound-call" type="xs : boolean" def ault="f alse" 
minOccurs= " " / > 

<xs : element name =" reveal -identity- to -target" type="ss : reveal -URI -opt ions -type" 
def ault = " true " minOccurs= " " / > 
</xs : sequence > 
</xs : complexType> 
<xs : element name="NoReplyTimer" > 
<xs : simpleType> 

<xs : restriction base="xs ipositivelnteger" > 
<xs iminlnclusive value="5"/> 
<xs imaxinclusive value="180"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : element > 
</xs : schema> 

4.9.3 XML schema for indication of supported conditions and actions 

?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www. w3 . org/2 01/XMLSchema" 
xmlns : ss="http : //uri . etsi .org/ngn/params/xml/simservs/xcap" 

targetNamespace="http : //uri .etsi .org/ngn/params/xml/simservs/xcap" elementFormDefault=" qualified" 
attributeFormDef ault =" unqualified" > 
<xs : annotation> 

<xs : documentation xml : lang="en" > 

This schema defines elements that are used to inform the UE which conditions and actions the 
network support . 
</xs : documentation> 
</xs : annotation> 

<xs : include schemaLocat ion="XCAP .xsd"/> 

<xs : element name=" communication- divers ion- serv- cap" substitutionGroup="ss : absService" > 
<xs : complexType > 
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<xs : complexContent> 

<xs : extension base="ss : simservType" > 
<xs : sequence> 

<xs:element name="serv-cap-conditions" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs : element name="serv- cap -anonymous" type="ss : provisioned- type" 

minOccurs= " " / > 
<xs:element name="serv-cap-busy" type="ss :provisioned-type" 

minOccurs= " " / > 
<xs : element name="serv- cap- external -list" type="ss : provisioned- type" 

minOccurs= " " / > 
<xs : element name="serv- cap -identity" type="ss : provisioned- type" 

minOccurs= " " / > 
<xs : element name="serv- cap -media" type="ss : support ed-media- type" 

minOccurs= " " / > 
<xs : element name="serv- cap -not -registered" type="ss : provisioned- type" 

minOccurs= " " / > 
<xs : element name="serv- cap -no -answer" type="ss : provisioned- type" 

minOccurs= " " / > 
<xs : element name="serv- cap -not -reachable" type="ss : provisioned- type" 

minOccurs= " " / > 
<xs : element name="serv- cap-presence -status" type="ss : provisioned- type" 

minOccurs= " " / > 
<xs : element name="serv- cap -rule -deactivated" type="ss : provisioned- type" 

minOccurs= " " / > 
<xs : element name="serv- cap -validity" type="ss : provisioned- type" 
minOccurs= " " / > 
</xs : sequence> 
</xs : complexType> 
</xs : element > 

<xs:element name="serv-cap-actions" minOccurs="0" > 
<xs : complexType> 
<xs : sequence> 

<xs : element name="serv- cap -target" type="ss : provisioned- target -type" 

minOccurs= " " / > 
<xs : element name="serv- cap -notify- caller" type="ss : provisioned- type" 

minOccurs= " " / > 
<xs : element name="serv- cap -notify- served- user" type="ss : provisioned- type" 

minOccurs= " " / > 
<xs : element name= "serv- cap- not ify-served-user- on- outbound- call" 

type="ss : provisioned- type" minOccurs="0"/> 
<xs : element name=" serv- cap -reveal -identity- to -caller" 

type="ss : provisioned- type" minOccurs="0"/> 
<xs : element name=" serv- cap- reveal -served-user- identity- to- caller" 

type="ss : provisioned- type" minOccurs="0"/> 
<xs : element name=" serv- cap -reveal -identity- to -target" 
type="ss : provisioned- type" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element > 
</xs : schema> 



4.10 Service Configuration of Communication Diversion 
Notification 

4.10.1 Structure of the XIVIL Document 
4.10.1.0 Examples 

Communication Diversion Notification documents are used for subscribing to the CDIVN service as well as for 
receiving the notification information about the various communication diversions. 

An instance of the communication diversion notification subscription document is shown below. 
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<comm-div-info> 

<comm-div-subs-inf o> 

<comm-div- select ion- criteria> 

< originating- user- select ion- criteria> 
<user-info> 

<user- name >Boss< /originating- user- name > 
<user-URI> 

sip ibossoof f ice . com 
</user-URI> 
</user-info> 
</ or iginating-user- select ion- criteria> 
<diver s ion- time -select ion- criteria> 
< time- range > 
<start-time>1999-05-31T13 : 20 : 00-05 : 0</start-time> 

<end-time>2006-05-06T13 : 20 : 00-05 : 0</end-time> </time-range> 
< /divers ion- time -select ion- criteria> 
<divers ion- reason- select ion- criteria> 

<divers ion- reason- info >4 04 3 02 < /diversion- reason- info> 
< /divers ion- reason- select ion- criteria> 
< /comm-div- select ion- criteria> 
<comm-div-ntfy-trigger-criteria> 

<notif icat ion- time -select ion- criteria > 
< time- range > 
<start-time>1999-05-31T13 :20 : 00-05 : 0</start-time> 

<end-time>2 06-05-06T13 : 20 : 00-05 : 00</end-time> </time-range> 
</notif icat ion- time -select ion- criteria > 
</comm-div-ntfy-trigger-criteria> 
</ comm-div- subs -info 
< /comm-div- info > 

Communication Diversion Notification documents have the following structure. 

<comm-div-inf o> 

<comm-div-ntfy-inf o> 

< originating- user- info > 

<user- name >Boss< /user- name > 
<user-URI>sip :boss@of f ice . com</user-URI> 
</originating-user-info> 
<divert ing- user- info > 

sip : aliceOof f ice . com 
< /divert ing- user- info > 
<diverted-to-user-inf o> 

sip iboboof f ice . com 
< /diverted- to -user- info> 

<diversion-time-info>1999-06-01T13 : 20 : 00-05 : 0</diversion-time-inf o> 
<divers ion- reason- info >4 04 
</comm-div-ntfy-info> 
</ comm-div- info > 



4.10.1.1 Communication Diversion Information 

4.10.1.1.0 General 

The Communication Diversion Information serves two purposes: 

in the SUBSCRIBE method, it carries the filter criteria for selecting specific communication diversions of the 
user which should be notified; 

selecting the information about the Communication Diversion, which has to be notified to the user in the 
corresponding NOTIFY request. 

4.10.1.1.1 Communication Diversion Subscription Information 

4.10.1.1.1.0 General 

The Communication Diversion Subscription Information allows the user to specify various filter criteria for selecting 
and controlling the amount of information in the notification of his/her communication diversion. This element has the 
following sub-elements. 
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4.10.1.1.1.1 Communication Diversion Selection Criteria 

The user would be able to select a specific subset of the overall communication diversions for notification. This helps 
the user to focus only on those communication diversions which may be important (e.g. "let me know whenever calls 
from my boss get diverted"). The user is able to set the following criteria for selecting the communication diversions 
which have to be notified. 

1) Identity of the Originating party: 

The URI specified over here will be compared with the URI (Identity) of the Originating party in the incoming 
communication. Only if there is a match, then information about the diversion of this specific communication 
would be selected for notification to the Diverting user. This is an optional parameter. If absent, then all 
diversions for communications from any Originating party would be considered for notification, subject to other 
filter criteria. 

2) Identity of the Diverting party: 

The URI specified over here will be compared with the Request-URI of the Diverting user, for which a 
communication has been diverted. Only if there is a match, then information about this specific communication 
diversion would be notified to the subscribing user. This is an optional parameter. If absent, then communication 
diversions towards all registered contacts of the subscribing user would be considered for notification, subject to 
other filter criteria. 

3) Identity of the Diverted-To party: 

The URI specified over here will be compared with the URI of the Diverted-to party, to whom the 
communication has been diverted. Only if there is a match, then information about this specific communication 
diversion would be notified to the subscribing user. This is an optional parameter. If absent, then communication 
diversions towards any Diverted-To party would be considered for notification, subject to other filter criteria. 

4) Time-Range of the Communication Diversion: 

This specifies a time-range, within which all communication diversions would be notified to the subscribing 
user. If present, then any communication diversion outside of this time-range would NOT be notified to the 
Diverting user. This is an optional parameter. If absent, then Communication Diversions happening at any time 
would be considered for notification, subject to other filter criteria. A time zone should be indicated. If a time 
zone is not indicated the SUBSCRIBE shall be rejected with a SIP 489. 

5) Reason for the Communication Diversion: 

The Diverting user can select that only those communication diversions which match the herein specified 
reasons be notified (see annex C). This is an optional parameter. If absent, then all communication diversions 
resulting due to any reason would be considered for notification, subject to other filter criteria. 

4.1 0.1 .1 .1 .2 Communication Diversion Notification Trigger Criteria 

As a part of the body of the SUBSCRIBE request, the user may specify further criteria to trigger the notification of 
those communication diversions, which were selected by the above mentioned criteria. These criteria enable the user to 
trigger the notification based on the following; 

Time-Range: 

This specifies a time-range at which notifications of communication diversion can be sent to the user. It may be 
specified in the form of a time-interval to enable periodic triggering of notifications of communication diversions 
which took place in that time-interval. If absent, it indicates that notifications are sent immediately when the 
communication diversion takes place. A time zone should be indicated. If a time zone is not indicated the 
SUBSCRIBE shall be rejected with a SIP 489. 

- Presence-status: 

This specifies a presence state of the user, within which the user expects to receive notifications about 
communication diversions. If absent, it indicates that notifications are sent immediately irrespective of user's 
availability information. 

In addition, the user may overwrite the CDIVN Buffer Timer with the Notification Buffer Interval as part of the body of 
the SUBSCRIBE request. The Buffer Interval value is time up to which the CDIVN AS should buffer the notification if 
it cannot be delivered to the user at the time of CDIVN AS execution. The user will be notified if CDIVN activation is 
valid and the CDIVN Buffer Timer to provide the notification has not expired, as described in clause 4.2.1. 

Notification Buffer Interval: 

This specifies an optional element (in seconds) to overwrite the CDIVN Buffer Timer for which the CDIVN AS 
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should store the CDIV Notification, if it cannot be dehvered to the user, as per the criteria configured above. For 
example this would be required for buffering the notifications, if the user is logged out and the diversion is 
triggered due to CFNL/CFNRc, resulting in CDIVN for that diversion. The user may set Notification Buffer 
Interval value in seconds to a maximum value of 1 day. Also, if not configured by the user, the default value of 1 
day (as configured by the network provider) is applicable. 

4.10.1 .1 .1 .3 Communication Diversion Information Selection Criteria 

As a part of the body of the SUBSCRIBE request, the user may specify further criteria to enable/disable which 
information about the communication diversion should be notified. By default, all information about a communication 
diversion would be notified. However, the user may use the following elements for DISABLING a particular kind of 
information from being notified. 

1) Information about the Originating party. 

2) URI of the Diverting party. 

3) URI of the Diverted-To party. 

4) Time of the Communication Diversion. 

5) Reason for the Communication Diversion. 

6) Identity of the rule which triggered the Communication Diversion. 

4.10.1.1.2 Communication Diversion Notification Information 

The body of a notification of communication diversion would contain information about the communication diversion, 
as selected by the various filter criteria configured by the user in the body of the SUBSCRIBE request. If the 
SUBSCRIBE request did not contain a message body, then all possible information about the communication diversion 
is notified to the User. 

The notifications generated by the server shall be in one of the formats specified in the Accept header field in the 
SUBSCRIBE request. The XML event package is sent as the body of the NOTIFY request, would contain the following 
information (subject to the filter criteria) selected by the user. 

1) Identity of the Originating party: 

This helps the Diverting user in knowing whose communication was diverted. 

2) Information of the Diverting party: 

The Request-URI of the INVITE request before the Communication Diversion Service was executed, is 
informed to the subscribing user. 

3) Information about the Diverted-To party: 

The Public User Identity of the Diverted-to User, to whom the communication is being diverted, is informed to 
the subscribing user. 

4) Time of the Communication Diversion: 

The time of the Communication Diversion is informed to the subscribing user. A time zone shall be indicated. 

5) Reason for the Communication Diversion: 

The Reason for this communication diversion is the same as the Reason Parameter as provisioned according to 
clause 4.10.LLLL It enables the subscriber to filter on diversion notifications for a particular cause. 

6) Communication Diversion Rule: 

This information identifies the Communication Diversion Rule as mentioned in clause 4.9. L2 which was 
executed to result in the communication diversion, which is being notified to the user. It contains the "id" 
attribute of Communication Diversion Rule defined in RFC 4745 [18]. 

4.10.2 XML Schema 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xs : schema 

targetNamespace="http : //uri . etsi . org/ngn/params/xml/comm-div-info" 
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xmins:tns="http: //uri . etsi . org/ngn/params/xml/comm-div-info" 

xmlns :xs="http: //www.w3 . org/2 1/XMLSchema" 

xmins="http : //uri . etsi . org/ngn/params/xml/comm-div-info" 

elementFormDefault=" qualified" 
attributeFormDefault=" unqualified" > 

< ! - - 

This import brings in the XML language definition 

- - > 

<xs : import namespace="http : //www. w3 .org/XML/ 1998 /namespace" 
schemaLocation="http : //www. w3 .org/2 01/0 3/xml .xsd"/> 

< ! - - 

Communication Diversion Information. This is the top-level XML element 

- - > 

<xs : element name="comm-div-inf o" 
type="comm-div-inf o-type" /> 

< ! - - 

Communication Diversion Information Type. This is the top-level XML element 

- - > 

<xs : complexType name="comm-div-info-type" > 
<xs : sequence> 

<xs : element name="comm-div-subs-info" 

type="comm-div-subs-info-type" minOccurs=" 0" /> 
<xs : element name="comm-div-ntfy-info" 

type="comm-div-ntfy- info-type" minOccurs="0" /> 
<xs : any namespace="##other" processContents="lax" 
minOccur s = " " maxOccur s = " unbounded " / > 
</xs : sequence> 

<xs : attribute name=" entity" type="xs : anyURI" 
use= " required" / > 
</xs : complexType > 

< ! 

Communication Diversion Subscription Type. 
Used at Subscription time to 

select Communication Diversions for notification, 

when to notify them and 

what to notify. 

- - > 

<xs : complexType name ="comm-div- subs -info- type "> 
<xs : sequence> 

<xs : element name="comm-div-selection-criteria" 
type="comm-div- select ion- criteria -type" 
minOccurs="0" /> 
<xs : element name="comm-div-ntfy-trigger-criteria" 
type="comm-div-ntfy- trigger- criteria -type" 
minOccurs="0" /> 
<xs : element name="comm-div-info-selection-criteria" 
type="comm-div- info -select ion- criteria -type" 
minOccurs="0" /> 
<xs : any namespace="##other" processContents="lax" 
minOccurs=" 0" maxOccurs=" unbounded" /> 
</xs : sequence> 

<xs : anyAt tribute namespace="##other" processContents="lax"/> 
</xs : complexType> 

< ! 

Communication Diversion Notification Information Type 

Used while notifying the User about the Communication Diversion 

- - > 

<xs : complexType name="comm-div-ntfy- info-type" > 
<xs : sequence> 

<xs : element name="originating-user-info" 
type="user-info-type" minOccurs="0" /> 
<xs : element name="diverting-user-info" 

type="xs : anyURI" minOccurs="0" /> 
<xs : element name="diverted-to-user-info" 

type="xs : anyURI" minOccurs=" 0" /> 
<xs : element name="diversion-time-inf o" 

type="xs idateTime" minOccurs=" 0" /> 
<xs : element name="diversion-reason-info" 

type="diversion-reason-info-type" minOccurs=" 0" /> 
<xs : element name="diversion-rule-info" 

type="diversion-rule-info-type" minOccurs=" 0" /> 
<xs : any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs=" unbounded" /> 
</xs : sequence> 

<xs : anyAt tribute namespace="##other" processContents="lax"/> 
</xs : complexType> 

< ! - - 

COMMUNICATION DIVERSION SELECTION CRITERIA 
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<xs : complexType name="comm-div-selection-criteria-type" > 
<xs : sequence> 

<xs : element name="originating-user-selection-criteria" 
type=" user- select ion- criteria -type" 
minOccurs="0" /> 
<xs : element name="diverting-user-selection-criteria" 
type="xs : anyURI" 
minOccurs="0" /> 
<xs : element name="diverted-to-user-selection-criteria" 
type="xs : anyURI" 
minOccurs="0" /> 
<xs : element name="diversion-time-selection-criteria" 
type=" time -range -select ion- criteria -type" 
minOccurs="0" /> 
<xs : element name="diversion-reason-selection-criteria" 
type=" divers ion- reason- select ion- criteria -type" 
minOccurs="0" /> 
<xs : any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs=" unbounded" /> 
</xs : sequence > 

<xs : anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType> 

< ! - - 

COMMUNICATION DIVERSION NOTIFICATION TRIGGER CRITERIA 

- - > 

<xs : complexType name ="comm-div-ntfy- trigger- criteria -type" > 
<xs : sequence> 

<xs : element name="notif ication-time-selection-criteria" 
type=" time -range -select ion- criteria -type" 
minOccurs="0" /> 
<xs : element name="presence-status-selection-criteria" 
type= "presence- status -select ion- criteria- type" 
minOccurs="0" /> 
<xs:element name="notif ication-buf f er-interval" minOccurs=" 0" def ault="86400" > 
<xs : simpleType> 

<xs : restriction base="xs : integer" > 
<xs :maxlnclusive value="86400"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : element > 

<xs : any namespace="##other" processContents="lax" 
minOccurs=" 0" maxOccurs=" unbounded" /> 
</xs : sequence> 

<xs : anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType> 

< ! - - 

COMMUNICATION DIVERSION INFORMATION SELECTION CRITERIA 

- - > 

<xs : complexType name="comm-div-info-selection-criteria-type" > 
<xs : sequence> 

<xs : element name="disable-originating-user-info" 

type="xs : boolean" def ault="f alse" minOccurs=" 0" /> 
<xs : element name="disable-diverting-user-info" 

type="xs : boolean" def ault="f alse" minOccurs=" 0" /> 
<xs : element name="disable-diverted-to-user-info" 

type="xs : boolean" def ault="f alse" minOccurs="0" /> 
<xs : element name="disable-diversion-time-info" 

type="xs : boolean" def ault="f alse" minOccurs="0" /> 
<xs : element name="disable-diversion-reason-info" 

type="xs : boolean" def ault="f alse" minOccurs="0" /> 
<xs : element name="disable-diversion-rule-info" 

type="xs : boolean" def ault="f alse" minOccurs=" 0" /> 
<xs : any namespace="##other" processContents="lax" 
minOccur s = " " maxOccur s = " unbounded " / > 
</xs : sequence> 

<xs : anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType > 

<!-- User Info Type --> 
<xs : complexType name="user-inf o-type" > 
<xs : sequence> 

<xs:element name="user-name" type="xs : string" minOccurs=" 0" maxOccurs="l"/> 
<xs:element name="user-URI" type="xs : anyURI "/> 
</xs : sequence> 

<xs : anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType > 
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DIVERSION REASON INFO 



<xs : simpleType name="diversion-reason-info-types" > 

<xs : list itemType= "divers ion-reason- info- type" /> 
</xs : simpleType> 
<xs : simpleType name="diversion-reason-info-type" > 
<xs : restriction base="xs : integer" > 
<xs : enumeration value="404"/> 
<xs : enumeration value="486"/> 
<xs : enumeration value="408"/> 
<xs : enumeration value="302"/> 
<xs : enumeration value="487"/> 
<xs : enumeration value="480"/> 
<xs : enumeration value="503"/> 
</xs : restriction> 
</xs : simpleType> 

< ! - - 

DIVERSION RULE INFO 

- - > 

<xs : complexType name="diversion-rule-info-type" > 

<xs : sequence> 

<xs:element name="diversion-rule" type="xs : string" /> 

</xs : sequence> 

<xs : anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType > 

< ! - - 

ORIGINATING USER SELECTION CRITERIA 

- - > 

<xs : complexType name=" user- select ion- criteria -type" > 
<xs : sequence> 

<xs: element name="user-info" 

type=" user- info -type" minOccurs="0" 
maxOccurs="unbounded" /> 
</xs : sequence> 

<xs : anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType > 

< ! - - 

DIVERSION REASON SELECTION CRITERIA 

- - > 

<xs : complexType name="diversion-reason-selection-criteria-type" > 
<xs : sequence> 

<xs : element name="diversion-reason-info" 
type="diversion-reason-inf o-types"/> 
</xs : sequence> 

<xs : anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType> 

< ! - - 

TIME RANGE SELECTION CRITERIA 

- - > 

<xs : complexType name="time-range-selection-criteria-type" > 
<xs : sequence> 

<xs: element name=" time -range" 

type=" time -range -type" minOccurs=" 0" 
maxOccurs= "unbounded" /> 
</xs : sequence> 

<xs : anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType> 

< ! - - 

TIME RANGE INFO 

- - > 

<xs : complexType name=" time -range -type" > 
<xs : sequence> 

<xs:element name="start-time" type="xs :dateTime" /> 
<xs:element name="end-time" type="xs idateTime" /> 
</xs : sequence> 

<xs : anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType > 

< ! - - 

PRESENCE STATUS SELECTION CRITERIA 

- - > 

<xs : complexType name="presence-status-selection-criteria-type" > 
<xs : sequence> 

<xs : element name="presence-status-info" 

type= "presence- status -info- type" minOccurs=" 0" 
maxOccurs="unbounded" /> 
</xs : sequence> 
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<xs ranyAt tribute namespace="##other" processContents="lax"/> 
</xs : complexType> 
< ! - - 

PRESENCE STATUS INFo 
- - > 
<xs : complexType name="presence-status-info-type" > 

<xs : sequence> 

<xs: element name="presence-status" type="xs : string" /> 

</xs : sequence> 

<xs : anyAt tribute namespace="##other" processContents="lax"/> 
</xs : complexType > 
</xs : schema> 
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Annex A (informative): 
Signalling Flows 

A.1 Normal cases 



A. 1.1 Communication Forwarding unconditional 

Figure A.l shows an example signalling flow for a successful communication forwarding unconditional based on an AS 
providing the forwarding. 



1. INVITE 

lURkSIPURI~Bl ^ 



8. 181 Call is beeing 
,^ forwarded 



2. INVITE 

(URhSIPURI-i 



7. 181 C all is beeing forwarded 



1 10. Cx-UseH 

I txrc 1 



4. INVITE 

(URI^SIPURi-B) ^ 



5. CFUIogic 
is executed 



6. 181 Call Is beeing 
^ forwarded 



9. INVITE 

(URhSIPURI-C) 



11. INVITE 

(URhSIPURI-C) 



25. RTP Media 



12. INVITE 

lURkSIPURI-C) 



Figure A.1 : CFU AS based normal case 



User B has activated the CFU service. 



£75/ 



3GPP TS 24.604 version 1 1 .4.0 Release 1 1 45 ETSI TS 1 24 604 V1 1 .4.0 (201 2-1 0) 

User A is sending a communication request towards User B: 

1 )Initial INVITE request towards User B . - see example in table A. 1 . 1 - 1 . 

Table A.I. 1-1 : INVITE request (UE A to P-CSCF) 

INVITE sip:user2_publicl@homel .net ;gr=2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74c SIP/2 . 
Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: sip:User2_publicl@homel . net ;gr=2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74c 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 
Require: sec -agree 
Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; port-c=8642 ; 
port-s=7531 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6 ;comp=sigcomp>; +g. 3gpp . icsi - ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept : application/sdp, application/3gpp-ims+xml 

Accept-Contact : * ; +g. 3gpp . icsi - ref ="urn%3Aurn-7%3gpp-service . ims . icsi .mmtel" 
P- Preferred- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 99 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 

2) Initial INVITE request towards User B. The URI-B is subscribed to the CFU service. 

3 to 4) Using the IFC the INVITE is forwarded to the AS. 

5) Procedures for CFU are executed. 

6 to 8) Depending on the value of subscription option 'Originating user receives notification that his communication 
has been diverted (forwarded or deflected)', a 181 (Call Is Being Forwarded) response is sent towards the User A 
indicating that the communication is diverted. 

9) An INVITE request including URI-C as destination is sent back to the S-CSCF. Additional the History-Info 
header is included. - see example in table A.1.1-9. 
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Table A.1.1-9: INVITE request (AS to S-CSCF) 

INVITE sip:User-C@example.com;cause=302 SIP/2.0 
Via: SIP/2. 0/UDP as.homel.net;branch=z9hG4bK712z34 .1, 
SIP/2 . 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, 
SIP/2 . 0/UDP pcscfl.homel.net;branch=z9hG4bK240f34 .1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 6 7 

Record- Route : <sip : as .homel .net>, <sip:scscfl .homel .net ; lr>, <sip :pcscf 1 .homel .net ; lr> 
Route : <sip : scscf 1 . homel . net ; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
Privacy: 

From: <sip :userl_publicl®homel .net>; tag=17182 8 

To: sip:user2_publicl@homel . net ;gr=2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74c 
Call-ID: 
Cseq: 
Require : 
Proxy-Require : 
Supported: 
Security- Verify: 
Contact : 
Allow: 
Accept : 

Accept-Contact : 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

History- Info: <sip : user2_publicl@homel .net ;gr=2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74c; 
>index=l, <sip :User-C@example . com;cause=302>index=l . 1 
Content-Type : 
Content-Length : 



10) S-CSCF looks up to the HSS to identify the location of User-C. 
1 1 to 12) The communication is routed towards User-C. 
13 to 18) The 200 (OK) response is sent back to the User- A. 
19 to 24) The ACK request is send back to User-B. 
25)RTP media is established. 
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A. 1.2 Communication Deflection 

Figures A.2a and A.2b describe the Immediate CD feature the only difference compared to a regular CD is that in the 
regular CD case the "302 (Moved Temporarily) Moved Temporarily" is preceded by a "180 (Ringing) Ringing". 
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Figure A.2a 
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37. RTP Media 



Figure A.2b 

User B has activated the CD service. 

User A is sending a communication request towards User B: 

1 to 2) Initial INVITE request towards User B. The URI-B is subscribed to the CPU service. - see example in 
table A.l. 1-1 

2a to 3) Using IPC the INVITE request is forwarded to the AS. 

4 to 7) The INVITE request is forwarded to User B due to normal communication procedures. 

8 to 10) A 302 (Moved Temporarily) response with a contact header including the URI of the forwarded to user is 
sent back to the AS. 

1 l)The CD logic is executed. 

12 to 14) Depending on the value of subscription option 'Originating user receives notification that his 

communication has been diverted (forwarded or deflected)', a 181 (Call Is Being Porwarded) response is sent 
towards the User A indicating that the communication is diverted. 
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15) An INVITE request including URI-C as destination is sent back to the S-CSCF. Additional the History-Info 
header is included. - see example in table A.1.2-15. 

Table A.1.2-15: INVITE request (AS to S-CSCF) 

INVITE sipiUser-COexample .com;cause=480 SIP/2.0 
Via: SIP/2. 0/UDP as.homel.net;branch=z9hG4bK712z34 .1, 
SIP/2 .0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, 
SIP/2 .0/UDP pcscfl.homel.net;branch=z9hG4bK240f34 .1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 67 

Record- Route : <sip : as .homel .net>, <sip:scscfl .homel .net ; lr>, <sip :pcscf 1 .homel .net; lr> 
Route : <sip : scscf 1 . homel . net ; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : 
Privacy: 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: sip:user2_publicl@homel .net ;gr=2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74c 
Call-ID: 
Cseq: 
Require : 
Proxy-Require : 
Supported: 
Security-Verify: 
Contact : 
Allow: 
Accept : 

Accept-Contact : 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 
History- Info: <sip :user2_publicl@homel .net ,•gr=2ad8950e-4 8a5-4a74-8d99- 
ad76cc7f c74c?Reason=sip%3Bcause=302>index=l, <sip :User-C@example . com;cause=4 8 0>index=2 
Content-Type : 
Content-Length : 



16 to 18) An INVITE request including URI-C as destination is routed to UE C. 

19 to 24) A 180 (Ringing) response is sent back to the originating user including a History-Info header as shown 
above. If no restriction is given the diverted to user will be presented at the UE of user A. 

25 to 30) The 200 (OK) response is sent back to the User-A. 

31 to 36) The ACK request is sent back to User-B. 

37)RTP media is established. 
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A.1 .3 Communication forwarding on no reply 

Figures A. 3a and A.3b shows an example signalling flow for a successful communication forwarding on no reply based 
on an AS providing the forwarding. 
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Figure A.3a 
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4 0. 180 Rin ging 



37 . 180 R ingin g ^ 
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53. RTP Media 
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35 . 180 Ringing 



Figure A.3b 

User B has activated the CFNR service. 

User A is sending a communication request towards User B: 

1 to 2) Initial INVITE request towards User B. The URI-B is subscribed to the CPU service. - see example in 
table A.l. 1-1 

3) Using the IPC the INVITE is forwarded to the AS. 

4) The INVITE request is forwarded to User B due to normal communication procedures. 

5) The non-reply timer in the AS is started. 

6 to 7) The INVITE is forwarded to User B due to normal communication procedures. 

8 to 14) A 180 is sent back to the originating user indicating that the terminating UE is ringing. 

15)The timer expires. 
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16 to 18) Depending on the value of subscription option 'Originating user receives notification that his 

communication has been diverted (forwarded or deflected)', a 181 (Call Is Being Forwarded) response is sent 
towards the User A indicating that the communication is diverted. 

19 to 21) To release the communication to User B the AS sends a CANCEL request. 

22 to 27) A 487 (Request Terminated) response with a ACK request finalize the termination of the dialog between 
AS and UE:B. 

28 to 31) An INVITE request including URI-C as destination is sent back towards the UE:C. Additional the History- 
Info header is included. 

28) An INVITE request including URI-C as destination is sent back to the S-CSCF. Additional the History-Info 
header is included. - see example in table A. 1.3-28. 



Table A.I. 3-28: INVITE request (AS to S-CSCF) 



INVITE sip: User- COexample. com ;target=sip:user2_publicl@homel .net%3bgr%3S2ad8 95 0e-4 8a5-4a74-8d99- 
ad76cc7fc74;cause 408 SIP/2.0 

Via: SIP/2. 0/UDP as.homel.net;branch=z9hG4bK712z34 .1, 
SIP/2 . 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, 
SIP/2 . 0/UDP pcscf 1 .homel .net;branch=z9hG4bK240f 34 .1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 67 

Record- Route : <sip : as .homel .net>, <sip:scscfl .homel .net ; lr>, < sip : pcscf 1 .homel .net ; lr> 
Route : <sip : scscf 1 . homel . net ; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : 
Privacy: 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: sip:user2_publicl@homel .net ;gr=2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74c 
Call-ID: 
Cseq: 
Require : 
Proxy-Require : 
Supported: 
Security- Verify: 
Contact : 
Allow: 
Accept : 

Accept-Contact : 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 
History- Info: <sip :user2_publicl@homel .net ;gr=2ad8950e-4 8a5-4a74-8d99- 
ad76cc7f c74c; >index=l, <sip :User-C@example. com; target = sip :user2_publicl@homel .net%3bgr%3 62ad8 95 0e- 
4 8a5-4a74-8d99-ad76cc7fc74;cause 408>index=l . 1 
Content-Type : 
Content-Length : 

v= 
o= 
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29 to 31) An INVITE request including URI-C as destination is routed to UE C. 

32 to 34) The 200 (OK) response for the CANCEL request is sent back to the User-A. 

35 to 40) A 180 (Ringing) response is sent back to the originating user including a History-Info header as shown 
above. If no restriction is given the diverted to user will be presented at the UE of User A. 

41 to 46) The 200 (OK) response is sent back to the User-A. 

47 to 52 ) The ACK request is sent back to User-B. 

53)RTP media is established. 

A.1 .4 Communication Forwarding on Busy 

Figures A.4a and A.4b shows an example signalling flow for a successful communication forwarding on busy based on 
an AS providing the forwarding. 
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Figure A.4a 
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24. 180 Ringing 



23. 180 Ringing 



37. RTP Media 



UE- 
B 



Figure A.4b 
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A. 1.5 Communication Forwarding Not Logged-in (CFNL) 

Figures A.5 shows an example signalling flow for a successful communication forwarding on not logged-in based on an 
AS providing the forwarding. 
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(URhSIPURI-C) 



25. RTP Media 



12. INVITE 

(URI=SiPURi-C) 



Figure A.5 



A. 1.6 Communication Diversion Notification (CDIVN) 

Figure A.6a shows an example signalling flow for a successful communication diversion notification based on an AS 
providing the forwarding. 

Editor's Note: Details of the contents of the Notify for the CDIVN event package will be provided when the internet 
draft is stable. 
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Figure A.6a 

1 to 10) UE-B subscribing to the CDIVN services. - see example in table A. 1.1-1 
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1 1 to 12) INVITE request from caller to the Original Target (the Diverting User) URI-B. 

13) Based on Initial Filter Criteria (IFC) for User B, the initial INVITE request is forwarded to the AS which is 
serving the CPU Communication Diversion Service. 

14) INVITE request is forwarded to the AS. 

15) Procedures for CPU are executed. 

16 to 18) Depending on the value of subscription option 'Originating user receives notification that his 

communication has been diverted (forwarded or deflected)', a 181 (Call Is Being Forwarded) response is sent 
towards the User A indicating that the communication is diverted. 

19 to 21) An INVITE request including URI-C as destination is sent back to the S-CSCF. 

22) Procedures for CDIVN (Communication Diversion Notification) are executed. 

23) A notification message (NOTIFY request) is generated towards the User B (Diverting User), with information 
about the incoming Communication Diversion from User A being diverted to User C. 

24 to 25) NOTIFY request with "comm-div-info" message body is forwarded to UE-B. 

26 to -28) 200 (OK) response for the NOTIFY request from UE-B. 

29 to 34) 200 (OK) response for the INVITE request from UE-C. 

35 to 40) ACK request from UE-A to UE-C. 



A.1 .7 Service configuration 



UE 



AP 



1. HTTP GET 
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-1 0. HTTP 200 OK- 
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-4. HTTP GET- 



'S. HTTP 200 OK- 



-8. HTTP PUT- 



-9. HTTP 200 OK- 



Figure A.7: Service configuration example 

1. HTTP GET request (UE to AP) - see example in table A.1.7-1 

The UE wants to retrieve the supported conditions and actions for communication diversion from the AS. 

Table A.1.7-1 : HTTP GET request (UE to AP) 



GET /simservs .ngn. etsi .org/users/sip luseriohomel . net /simservs/ communication- divers ion- serv- cap 

HTTP/ 1.1 
Host : xcap .mnc012 .mcc34 5 . ipxuni . 3gppnetwork.org 
Date: Thu, 16 Jun 2011 10:50:33 GMT 
X-3GPP- Intended- Identity: "sip: user lohomel .net" 



2. HTTP 401 (Unathorized) response (AP to UE) - see example in table A. 1.7-2 
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Upon receiving an unauthorized HTTP GET request the AP authenticates the UE. 

Table A.I. 7-2: HTTP 401 (Unathorized) request (AP to UE) 



HTTP/1.1 401 Unauthorized 

Date: Thu, 16 Jun 2011 10:50:34 GMT 

WWW- Authenticate : Digest realm="xcap .mnc012 .mcc34 5 . ipxuni . 3gppnetwork.org" , 

nonce="47364c23432d2el31a5fb210812c" , qop=auth-int 
Content-Length: 



3. HTTP GET request (UE to AP) - see example in table A.1.7-3 

The UE repeats the HTTP GET request including the Authorization header. 

Table A.1.7-3: HTTP GET request (UE to AP) 



GET /simservs .ngn. etsi . org/users/sip :userl@homel . net /simservs/ communication- divers ion- serv- cap 

HTTP/1.1 
Host : xcap .mnc012 .mcc34 5 . ipxuni . 3gppnetwork.org 
Date: Thu, 16 Jun 2011 10:50:36 GMT 
Authorization: Digest realm="xcap .mnc012 .mcc34 5 . ipxuni . 3gppnetwork.org" , 

nonce="47364c23432d2el31a5fb2 10812c" , username= " sip : user lohomel .net " , qop=auth-int , 

uri=" /simservs .ngn. etsi .org/users/sip: user lohomel .net/simservs/communication-diversion- 

serv-cap" , response="2c8ee200cec7f 6e966c932a9242554e4" , 

cnonce="dcd99agsfgf sa8b7102dd2f 0e8bl" , nc=00000001 
X-3GPP- Intended- Identity: "sip :userl@homel .net" 



4. HTTP GET request (AP to AS) - see example in table A.1.7-4 

The AP forwards the HTTP GET request to the AS. 

Table A.1.7-4: HTTP GET request (AP to AS) 



GET /simservs .ngn. etsi .org/users/sip :userl®homel .net /simservs /communication- divers ion- serv- cap 

HTTP/1.1 
Host : xcap .mnc012 .mcc34 5 . ipxuni . 3gppnetwork. org 
Via: HTTP/1.1 ap.homel.net 
Date: Thu, 16 Jun 2011 10:50:38 GMT 
X-3GPP-Asserted- Identity: "sip :userl®homel .net" 



5. HTTP 200 (OK) response (AS to AP) - see example in table A.1.7-5 

The AS returns the supported conditions and actions for communication diversion. 

The <serv-cap-media> child element of the <serv-cap-conditions> element describes that audio and video media are 
allowed to be used as Communication Diversion rule conditions. The other child elements of the <serv-cap-conditions> 
element list the conditions that are not provisioned for the user. If a service capability for a condition is not listed from 
the list of conditions specified in subclause 4.9.1.3 then the condition is provisioned for the user. The following 
conditions are provisioned: busy, not-registered, no-answer, not-reachable. 

The <serv-cap-target> child element of the <serv-cap-actions> element describes that the target needs to correspond to a 
telephone number. The other child elements of the <serv-cap-actions> element list the actions that are not provisioned 
for the user. If a service capability for an action is not listed from the list of actions specified in subclause 4.9.1.4 then 
the action is provisioned for the user. In this example, there are no other actions provisioned. 
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Table A.I. 7-5: HTTP 200 (OK) response (AS to AP) 



HTTP/1.1 200 OK 

Date: Thu, 16 Jun 2011 10:50:40 GMT 

Etag: "eti87" 

Content-Type: application/xcap-el+xml; charset="utf -8" 

Content-Length: (...) 

<communication-diversion-serv-cap active="true" > 
<serv- cap -condit ions > 

<serv-cap-anonymous provisioned="f alse" ></serv-cap-anonymous> 
<serv- cap- external -list provisioned=" false" ></serv- cap- external- list > 
<serv- cap -identity provisioned=" false" ></serv-cap-identity> 
<serv- cap -media > 

<media>audio< /media > 
<media>video< /media > 
</serv- cap -media > 

<serv- cap-presence- status provisioned=" false" ></serv- cap-presence- status > 
<serv- cap -rule -deactivated provisioned="f alse" ></serv- cap- rule-deactivated> 
<serv- cap -validity provisioned=" false" ></serv-cap-validity> 
< /serv- cap -condit ions > 
<serv- cap -act ions > 

< serv- cap -target> 

< telephony- type /> 
< /serv- cap -target> 
< serv- cap -notify- caller provisioned=" false" > 

< /serv- cap- not ify-caller> 
<serv-cap-notify-served-user provisioned=" false" > 

</ serv- cap- not ify-served-user> 
< serv- cap- not ify-served-user- on- outbound- call provisioned=" false" > 
</ serv- cap- not ify-served-user- on- outbound- call> 
< serv- cap -reveal -identity- to -caller provisioned=" false" > 

< /serv- cap -cap -reveal -identity- to -caller> 
< serv- cap- reveal -served-user- identity- to -caller provisioned=" false" > 

</ serv- cap- reveal -served-user- identity- to- caller> 
< serv- cap -reveal -identity- to -target provisioned=" false" > 
< /serv- cap -reveal -identity- to -target> 
< /serv- cap -act ions > 
</ communication- divers ion- serv- cap > 



6. HTTP 200 (OK) response (AP to UE) - see example in table A.1.7-6 

The AP routes the HTTP 200 (OK) response to the UE. 

Table A.1.7-6: HTTP 200 (OK) response (AP to UE) 



HTTP/ 1.1 200 OK 

Via: HTTP/ 1.1 ap.homel.net 

Date: Thu, 16 Jun 2011 10:50:42 GMT 

Authentication- Info: nextnonce="e96 6c32a9242 5 5e42c8ee2 0ce7f 6" 

Etag: "eti87" 

Content-Type: application/simservs+xml; charset="utf -8" 

Content-Length: (...) 

(...) 



7. HTTP PUT request (UE to AP) - see example in table A.1.7-7 

The UE creates a new rule to activate the CFU service. If a rule with id="rulel" previously existed then the new rule 
replaces that rule. The rule has an empty <conditions> element. 
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Table A.1.7-7: HTTP PUT request (UE to AP) 



PUT /simservs . ngn . etsi . org/users/sip : useriohomel . net/simservs/~~/communication- 
diversion/ruleset/rule%5b@id=%22rulel%22%5d HTTP/1 . 1 

Host : xcap .mnc012 .mcc34 5 . ipxuni . 3gppnetwork.org 

Date: Thu, 16 Jun 2011 10:52:33 GMT 

Authorization: Digest realm="xcap .mnc012 .mcc34 5 . ipxuni . 3gppnetwork.org" , 

nonce="e966c3 2a9242 55e42c8ee2 0ce7f 6" , username=" sip: useriohomel .net " , qop=auth-int , 
uri=" /simservs .ngn. etsi .org/users/sip: useriohomel .net /simservs/ --/communication- 
diversion/ruleset" , response="adq3283hww88whhjw98822333ddd32 " , 
cnonce="wqesatt874873j3gg3kk39944hhhee" , nc=00000001 

X- 3GPP- Intended- Identity : sip : useriohomel .net 

Content-Type: application/xcap-el+xml; charset="utf -8" 

Content-Length: (...) 

<cp:rule id="rulel"> 

<cp : conditions> 

</cp : conditions> 

<cp : actions> 

<forward-to> 

<target>tel : +15556667777</target> 
<not i f y- caller >t rue < /notify- caller > 
</forward-to> 
</cp : actions> 
</cp : rule> 



8. HTTP PUT request (AP to AS) - see example in table A.1.7-8 

The AP forwards the HTTP PUT request to the AS. 

Table A.1.7-8: HTTP PUT request (AP to AS) 



PUT /simservs . ngn . etsi . org/users/sip : useriohomel . net/simservs/~~/communication- 

diversion/ruleset/rule%5b@id=%22rulel%22%5d HTTP/1 . 1 
Host : xcap .mnc012 .mcc34 5 . ipxuni . 3gppnetwork.org 
Via: HTTP/1.1 ap.homel.net 
Date: Thu, 16 Jun 2011 10:52:35 GMT 
X-3GPP- Asserted- Identity: sip : useriohomel .net 
Content-Type: application/xcap-el+xml; charset="utf -8" 
Content-Length: (...) 

(...) 



9. HTTP 200 (OK) response (AS to AP) - see example in table A.1.7-9 

The AS acknowledges the addition of the new CFU rule with a HTTP 200 (OK) response. 

Table A.1.7-9: HTTP 200 (OK) response (AS to AP) 



HTTP/ 1.1 200 OK 

Date: Thu, 16 Jun 2011 10:52:37 GMT 

Etag: "efefefef" 

Content-Length: 



10. HTTP 200 (OK) response (AP to UE) - see example in table A.1.7-10 

The AP routes the HTTP 200 (OK) response to the UE. 

Table A.1.7-10: 200 (OK) response (AP to UE) 



HTTP/1.1 200 OK 
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GMT 
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A.2 Interworking 

A.2.1 Communication Forwarding unconditional 

Figure A.6b shows an example signalling flow for a successful communication forwarding unconditional based on an 
AS providing the forwarding, with the originating user in the PSTN. 
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Figure A.6b: Call Forwarding Unconditional 



A.2. 2 Communication Deflection 

Figure A.7 shows an example signalling flow for a successful communication deflection based on an AS providing the 
forwarding, with the originating user in the PSTN. 
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Annex B (informative): 
Example of filter criteria 



This annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria 
evaluation. 

An example of an IFC when the CDIV supplementaryservice is active at the diverting S-CSCF is: 

- Method: INVITE. 
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Annex C (informative): 
Coding considerations 



This annex provides an interpretation of the coding of the cause-param URI parameter specified in RFC 4458 [14] 
The cause specified in RFC 4458 [14] has the following syntax: 



cause-param 



"cause" EQUAL Status -Code 



The Status-Code is originally specified in RFC 3261 [6] as a sequence of 3 digits. It is noted that the Status-Code 
simply indicates that it is composed of 3 digits, without indicating the list of possible values. In particular, Status-Code 
is not bound to and must not be confused with the 3 digit numbers defined for SIP responses in RFC 3261 [6]. The 
Status-Code is used to hold the redirecting reason. 

For the purpose of legibility, the cause-param specified in RFC 4458 [14] is interpreted according to the following 
syntax: 

"cause" EQUAL Status -Code 

Unknown/Not available 

User Busy 

No Reply 

Unconditional 

Deflection during alerting 

Deflection during immediate response 

Mobile subscriber not reachable 



cause-param 


- 


"caus 


Status-Code 


= 


"404" 




/ 


"48S" 




/ 


"408" 




/ 


"302" 




/ 


"487" 




/ 


"480" 




/ 


"503" 
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Annex D (informative): 
Void 
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Annex E (informative): 
Change history 
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